SOA is being used to support organizations in collaboration in the creation of virtual organizations for mutual benefit. A crucial building block in the creation of virtual organizations is the federation of identity information, allowing transparent access across security domains for users based on trustrelationships that are established between the participating organizations. While WS-Federation does not address the specifics of how trust relationships are established, itprovides a metadata exchange framework to allow organizations to provide services that leverage these trust relationships. WS-Federation is a component of the WS-Security family of standards and has been created to support the federation of security domains, which allows users whose identity information exists in one security domain to access resources in another security domain. This is enabled by the abilityto broker identity data including indentity, authentication, authorization and attribute information between security domains, through the use of mechanisms selected based on the relationship of trust that exists between the security domains. WS-Federation provides astandard way for security domains to exchange metadata in order to indicate the trust relationships between these security domains. This is an overview of the contents of the WS-Federation Version1.1 Specification published in December 2006.
An important aspect of the WS-Federation approach is that an organization needs to be able to use their existing identity management infrastructures in order to support identity federation, with minimal new investment required in order to participate. For this reason, the range of supported security tokens, attributes and discovery approaches are designed to support the range of technologies that are already in place as a foundation. The approach also does not specify specific trust toplogies, tools and relationships, deliberately in order to provide flexibility to allow the ability to participate in identity federation independently of what the existing infrastructure consists of. Furthermore, the approach is designed to be extensible to make it easy to integrate new approaches to identity and trust management that may be developed going forward.
WS-Federation exists within a family of other WS-*standards. It rests on a foundation of WS-Security and WS-Trust that contain the primitives necessary to define security tokens, trust topologies and security infrastructures. The primitives defined in WS-Policy and WS-SecurityPolicy, along with extensions that are defined as part of theWS-Federation specification, are indended to support the definition of policies that identify what the supported and required components of a federation are by participating members, and what the choices are for communicating the policy information between federation participants.
There are two types of requesters that are supported by WS-Federation, Web services and Web browser based requesters. Identity mapping could be done at the target service, the requestor, the identity provider, or an intermediate security token service. In order to provide privacy inthe situation where identity mapping is performed by the resource that the user is accessing, WS-Federation includes the specification of a service called a pseudonym service that provides the federated identity for the mapping. In this situation therequestor obtains, through the leverage of these trust relationships, a security token that the target service can accept. In this case, the target service has no way of knowing that the requestor is in another security domain.
2. Alternate Federation and Trust Model
In the case where there do not exist trust relationships between the requestor and its identity provider/security token service, or between the target service and its own identity provider/token service, the target service will need to use its own security token service to validate the token provided by the requestor. In this case, the target service is aware that the requestor is in another security domain.
3. Indirect Trust Model
In the indirect trust model, there is no direct trust relationship between the requestor's security token service and the target service's security token service, but trust relationships that both securitytoken services have with a third party security token service are leveraged in order to provide a security token to the requestor that will work with thetarget service.
4. Multiple Trust Domain Model
In the multiple trust domain model, the requestor accesses target services that exist in more than one other security domain, by leveraging trust relationships between the requestor's security token service and the security token services for the set of target services.
5. Trust Between Requestor-Resource and Resource-Delegate Resource
In this trust topology, a requestor accesses a target service leveraging a trust relationship between its security token service andthe target service's security token service, and the target service delegates its work to a delegate service leveraging a trust relationship between the target service's security token service and the delegate service's security token service.
6. No Trust Relationship Between Resource Providers
This trust topology exists when a requestor accesses a target service leveraging a trust relationship between its security token service and the target service's security token service, and the target service's security token service has no trust relationship with a delegateservice's security token service, but there is a trust relationship between the requestor's security token service and the delegate service's security token service.
Identity Providers and Security Token Services
A Security Token Service (STS) is a service that will issue and exchange security tokens. A Webservice that conforms to the WS-Trust specification may act as its own STS. Another type of STS is an identity provider that authenticates users and issues security tokens that contain identity claims. Sometimes an identityprovider and STS will reside in the same service. In other cases, an identity provider can access an STS to provide security tokens to requestors after they have been authenticated by the identity provider.
Attributes and Pseudonyms
Attributes are used to exchange information about requestors that are not already included in security tokens or requests. Pseudonym services provide account management for pseudonyms and the ability to issue, update and revoke pseudonyms
Federation Metadata
Federation metadata can be represented as a document that contains metadata for an endpoint existing in one or more federations, for one or more services, with one or more MEPRs per service, can refer to external metadata documents, and can be contained inside a service's WSDL description.
Federation Metadata Document
The federation metadata document is structured as follows:
<?xml version="1.0" encoding="..."?>
<fed:FederationMetadata xmlns fed="..." ...>
<fed:Federation[FederationID="..."= ...>
[FederationMetadata]
</fed:Federation>
[Signature]
</fed:FederationMetadata>
The FederationID attribute is an optional URI designating a pecific federation, but can be left out which is interpreted as the default federation, or at most one Federation element in the FederationMetadata document. The [Federation Metadata] property consists of a set of optional metadata statements. The [Signature] property consists of an XML Digital Signature on the metadata document content, which provides integrity and data origin authentication for the metadata document.
Any federation participant's metadata document can containthe following metadata elements
1. mex:MetadataReference
2. fed:AttributeServiceEndpoint
A Security Token Service's metadata document can contain the following metadata elements:
1. fed:TokenSigningKeyInfo
2. fed:PseudonumServiceEndpoint
3. fed:SingleSignOutSubscriptionEndpoint
4. fed:TokenTypesOffered
5. fed:UriNamedClaimTypesOffered
6. fed:AutomaticPseudonyms
7. fed:IssuerNamesOffered
A Service Provider or Relying Party's (which can be aSecurity Token Service) metadata document can contain the following elements:
1. fed:TokenIssuerName
2. fed:TokenIssuerEndpoint
3. fed:TokenKeyTransferKeyInfo
4. fed:SingleSignoutNotificationEndpoint
In order to reference another metadata document, a mex:MetadataReference element is used which refers, using theWS-MetadataExchange specification, to another metadata document which has the same federation identification. Metadata documents can also share elements by using the fed:FederationInclude element and be named using URIs.
The TokenSigningKeyInfoElement of the Federation MetadataDocument
Security Token Services and other token issuers need to beable to indicate to metadata users what key it will use to sign security tokens that it issues. The fed:TokenSigningKeyInfo Element is used to specify this key and has the following structure:
<fed:TokenSigningKeyInfo ...>
<wsse:SecurityTokenReference>
...
</wsse:SecurityTokenReference>
</fed:TokenSigningKeyInfo>
The wsse:SecurityTokenReference can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.
The TokenKeyTransferKeyInfo Element of the FederationMetadata Document
Security Token Services and Relying Parties need to be able to indicate which key requestors need to use to encrypt key information that is to be sent to them. The fed:TokenKeyTransferKeyInfo element is used for this purpose and has the following structure:
<fed:TokenKeyTransferKeyInfo ...>
<wsse:SecurityTokenReference>
...
</wsse:SecurityTokenReference>
</fed:TokenKeyTransferKeyInfo>
The wsse:SecurityTokenReference element can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.
The IssuerNamesOffered Element of the Federation MetadataDocument
Token issuers can be part of a set of equivalent issuers. Relying parties need to verify that the token issuer is a member of the set in order to be able to use the token issuer. The fed:IssuerNamesOffered element is used for this purpose and has the following structure:
<fed:IssuerNamesOffered ...>
<fed:IssuerNameUri="xs:aURI" .../> ...
</fed:IssuerNamesOffered>
This element can be specific to a service or an endpoint.
The TokenIssuerName Element of the Federation MetadataDocument
Relying parties need to be able to indicate that they are included in a set of equivalent issuers. The fed:TokenIssuerName element is used for this purpose and has the following structure:
<fed:TokenIssuerName...>xs:aURI</fed:TokenIssuerName>
This element can be specific to a service or an endpoint.
The TokenIssuerEndpoint element of the Federation MetadataDocument
A relying party needs to be able to indicate to other federation members what Security Token Service that it trusts so that the other federation members can know where to go to get security tokens that can be used to access the relying party. TheTokenIssuerEndpoint element is used for this purpose and has the following structure:
<fed:TokenIssuerEndpoint>
wsa:EndpointReferenceType
</fed:TokenIssuerEndpoint>
The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.
The PseudonymServiceEndpoint Element of the FederationMetadata Document
Token issuers and Security Token Services need to be able to indicate which pseudonym service that services should use when they want to map user identities. ThePseudonymServiceEndpoint element is used for this purpose and has the following structure:
<fed:PseudonymServiceEndpoint>
wsa:EndpointReferenceType
</fed:PseudonymServiceEndpoint>
The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.
The AttributeServiceEndpoint Element of the FederationMetadata Document
Requestors need to be able to provide a way to indicate to services where to send queries for attribute information that may be required in order to process requests. The AttributeServiceEndpoint element is used for this purpose and has the following structure:
<fed:AttributeServiceEndpoint>
wsa:EndpointReferenceType
</fed:AttributeServiceEndpoint>
The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element is a service level element.
The SingleSignOutSubscriptionEndpoint Element of the Federation Metadata Document
Token issuers and Security Token Services need to be able to specify a subscription endpoint for them to send sign out messages to.
<fed:SingleSignOutSubscriptionEndpoint>
wsa:EndpointReferenceType
</fed:SingleSignOutSubscriptionEndpoint>
The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.
The SingleSignOutNofificationEndpoint Element of the Federation Metadata Document
Service providers and Security Token Services need to be able to register to receive notification when a requestor has signed out of the federation. The SingleSignOutNotification element is used for this purpose and has the following structure:
<fed:SingleSignOutNotificationEndpoint>
wsa:EndpointReferenceType
</fed:SingleSignOutNotificationEndpoint>
The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.
The TokenTypesOffered Element of the Federation Metadata Document
Token issuers and Security Token Services need to be able to indicate which token types they support. The TokenTypesOffered element is used for this purpose and has the following structure:
<fed:TokenTypesOffered ...>
<fed:TokenType Uri="xs:aURI" ...>
...
</fed:TokenType>
...
</fed:TokenTypesOffered>
One or more fed:TokenType elements are used to specify the set of token types that are provided. A URI attribute can be used to specify a token type. The TokenTypesOffered element is extensible. Additional elements and attributes can be included in the TokenTypesOffered and TokenType elements if they preserve the existing semantics of the WS-Federation specification.
The UriNamedClaimTypesOffered Element of the FederationMetadata Document
Token Issuers and Security Token Services need to be able to specify the set of claims that they offer to service providers given the identity of a requestor. The UriNemedClaimTypesOffered element is used for this purpose and has the following structure:
<fed:UriNamedClaimTypesOffered ...>
<fed:ClaimTypeUri="aURI" ...>
<fed:DisplayName...>xs:string</fed:DisplayName>
<fed:Description...>xs:string</fed:Description>
...
</fed:ClaimType>
...
</fed:UriNamedClaimTypesOffered>
The UriNamedClaimTypesOffered element is extensible. Additional elements and attributes can be included in the UriNamedClaimTypesOffered, ClaimType, DisplayName and Description elements if they preserve the existing semantics of the WS-Federation specification.
The AutomaticPseudonyms Element of the FederationMetadata Document
Token issuers and Security Token Services need to be able to indicate whether they either perform the automatic mapping of pseudonyms or otherwise perform identity mapping. The AutomaticPseudonyms element is used for this purpose and has the following structure:
<fed:AutomaticPseudonyms>
xs:boolean
</fed:AutomaticPseudonyms>
The Signature Property of the Federation Metadata Document
The Signature property of the metadata document is used to provide data origin authentication and data integrity for the federation metadata. XML Signature is recomended, and if used it is required that XML Exclusive Canonicalization is used.
Federation Metadata Discovery
If a relying party needs to obtain federation metadata given nothing more than the DNS host name of a service then the following processing order is recommended by the WS-Federation specification:
1. HTTPS GET, WS-Transfer/WS-ResourceTransfer GET (WS-Security is recommended), and HTTP GET are preferred in the listed order.
2. The federation ID should be used before accessing metadata using the default federation.
The federation metadata document can be contained within a service's WSDL description.
The recommended federation metadata path is as follows:
https://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml
or
http://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml
or
https://server-name/FederationMetadata/specification-version/FederationMetadata.xml
or
http://server-name/FederationMetadata/specification-version/FederationMetadata.xml
The FederatedMetadataHandler Header
Services may be configured with a pre-processing service that handles federation metadata requests. The FederatedMetadataHandler header is used to identify metadata requests for this purpose. This is accomplished by including the following element in the header of a SOAP
message:
<fed:FederationMetadataHandler .../>
The Metadata Exchange Dialect
The metadata exchange dialect is used when including the federation metadata documents as an element in a Web service's mex:Metadata element conforming to the WS-MetadataExchange specification. This is done by specifying the metadata dialect URI using an attribute on a mex:MetadataSection element which contains the Federation Metadata Document:
<mex:MetadataSection
Dialect="http://schemas.xmlsoap.org/ws/2006/12/federation">
<fed:FederationMetadata ...>
...
</fed:FederationMetadata>
</mex:MetadataSection>
This can be used to provide backward compatiblity as subsequent versions of the WS-Federation specification may be published.
Publishing Federation Metadata Location
The WS-Federation specification recommends that domains publish federation metadata using SRV resource records in DNS databases.
The _Service.Protocol.TargetDnsDomain is used to specify the available protocols by which the metadata is available, which may be one or more of HTTP, HTTPS or WS-Transfer/WS-ResourceTransfer, by specifying the owner name of the SRV record as:
1. _fedMetadata._http.TargetDnsDomain in order to indicate that metadata is available via HTTP
2. _fedMetadata._https.TargetDnsDomain in order to indicate that metadata is available via HTTPS
3. _fedMetadata._wsxrf._http.TargetDnsDomain in order to indicate that metadata is available via WS-Transfer/WS-ResourceTransfer
In addition, priority (load balance priority), weight (load balance weight), port (port that the service is available on) and target (domain name) information is included in the SRV record.
The WS-Federation specification recommends that metadata providers include a signature element and that metadata consumers validate the signature elements of federation metadata documents.
Federated Sign-Out
Federated sign-out is used to give relying parties the ability to reclaim resources that had been consumed in order to support a user session within the federation. Sign-out is accomplished by sending an optional message.
The Sign-Out Message
When a requestor chooses to terminate a federation Single Sign-On session they will send a Sign-Out message to the Identity Provider or Security Token Service that they used to authenticate within the federation with. The mssage structure is as follows:
<fed:SignOut wsu:Id="..." ...>
<fed:Realm>xs:aURI</fed:Realm>
<fed:SignOutBasis ...>...</fed:SignOutBasis>
...
</fed:SignOut>
...
</fed:SignOut>
The optional fed:Realm element indicates a realm that the sign-out is operational for. The mandatory fed:SignOutBasis can is used to specify the principal that is signing out. The optional ID element is a label for the SignOut message. The SignOut message is extensible. Additional elements and attributes are allowed to be included in the SignOut and SignOutBasis elements if they do not modify the semantics of the WS-Federation specification. The WS-Federation specification recommends that SignOut messages be signed in order to prevent SignOut of a principal by an unauthorized entity.
Federating the Sign-Out Message
In order to share sign-out information with all relying parties that a user has accessed in the federation, a method of sending federated sign-out messages is needed. This can be accomplished by having Security Token Services send sign-out messages to secondary Security Token Services, or by using WS-Eventing to create subscriptions to federated sign-out messages. These messages can be filtered in two ways.
<wsrt:Expression>
<fed:FilterPseudonyms>
<fed:PseudonymBasis>
<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>
</fed:PseudonymBasis>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
</fed:FilterPseudonyms>
</wsrt:Expression>
</wsrt:Get>
</S:Body>
</S:Envelope>
This is an example reply:
<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."
xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">
<S:Body>
<wsrt:GetResponse>
<wsrt:Result>
<fed:Pseudonym>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
<wsu:Expires>2007-02-18T20:04:00Z</wsu:Expires>
<fed:SecurityToken>...</fed:SecurityToken>
<fed:ProofToken>...</fed:ProofToken>
</fed:Pseudonym>
</wsrt:Result>
</wsrt:GetResponse>
</S:Body>
</S:Envelope>
Setting Pseudonyms
Pseudonyms are set in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to "Insert".
Here's an example:
<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."
xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">
<S:Body>
<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">
<wsrt:Expression Mode="Insert">
<fed:FilterPseudonyms>
<fed:PseudonymBasis>
<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>
</fed:PseudonymBasis>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
</fed:FilterPseudonyms>
</wsrt:Expression>
<wsrt:Value>
<fed:Pseudonym>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
<fed:SecurityToken>...</fed:SecurityToken>
<fed:ProofToken>...</fed:ProofToken>
</fed:Pseudonym>
</wsrt:Value>
</wsrt:Put>
</S:Body>
</S:Envelope>
Deleting Pseudonyms
Pseudonyms are deleted in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to"Remove".
Here's an example:
<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."
xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">
<S:Body>
<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">
<wsrt:Expression Mode="Remove">
<fed:FilterPseudonyms>
<fed:PseudonymBasis>
<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>
</fed:PseudonymBasis>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
</fed:FilterPseudonyms>
</wsrt:Expression>
</wsrt:Put>
</S:Body>
</S:Envelope>
Creating Pseudonyms
Pseudonyms are created in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Create element.
Here's an example:
<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."
xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">
<S:Body>
<wsrt:CreateDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">
<wsrt:Expression Mode="Insert">
<fed:FilterPseudonyms>
<fed:PseudonymBasis>
<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>
</fed:PseudonymBasis>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
</fed:FilterPseudonyms>
</wsrt:Expression>
<wsrt:Value>
<fed:Pseudonym>
<fed:RelativeTo>
<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>
</fed:RelativeTo>
<fed:SecurityToken>..</fed:SecurityToken>
<fed:ProofToken>...</fed:ProofToken>
</fed:Pseudonym>
</wsrt:Value>
</wsrt:Create>
</S:Body>
</S:Envelope>
Security Tokens and Pseudonyms
Pseudonyms services can associate a pseudonym with a security token. The requestor can storeand retrieve a security token that it receives from a Security Token Service, or the Security Token Service can store and retrieve the security token on behalf of the requestor. On the other hand, a requestor can communicate with a Security Token Service by sending a RequestSecurityToken element conforming to the WS-Trust specification, and receive a RequestSecurityTokenResponse element in return.
RequestSecurityToken and RequestSecurityTokenResponse Extensions
If a Security Token Service is mapping pseudonyms to present a unique pseudonym to a target service, security token requests can contain a fed:RequestPseudonym element in the RequestSecurityToken. The structure of the fed:RequestPseudonym element is as follows:
<fed:RequestPseudonym SingleUse="xs:boolean" Lookup="xs:boolean" ...>
...
</fed:RequestPseudonym>
The value of the SingleUse attribute is used to specify that a pseudonym shall be used only once. The value of the Lookup attributes specifies that a pseudonym associated with the scope that is indicated should be returned, or if the primary identity for the principal should be used regardless of the context. The RequestPseudonym element is extensible. Additional elements and attributes can be included in the RequestPseudonym element if they do not modify the semantics of the WS-Federation specification.
Security Tokens and RequestSsecurityToken and RequestSecurityTokenResponse Extensions
Pseudonym Services can also store usernames and passwords, symmetric keys and newly generated private keys along with the pseudonyms.
The ReferenceToken Element
Reference tokens are an extension to WS-Trust that were created as part of the WS-Federation specification. They enable RequestSecurityTokenResponse messages to return a reference to a token, secured with a proof token, leaving it up to the requestor to acquire the token itself.
The ReferenceToken element has the following structure:
<fed:ReferenceToken ...>
<fed:ReferenceEPR>wsa:EndpointReferenceType</fed:ReferenceEPR>
<fed:ReferenceDigest ...>xs:base64Binary</fed:ReferenceDigest>
<fed:ReferenceType ...>xs:anyURI</fed:ReferenceType>
<fed:SerialNo ...>...</fed:SerialNo>
...
</fed:ReferenceToken>
The ReferenceEPR element contains an endpoint reference that the request was sent to. The optional ReferenceDigest element contains an SHA1 digest of the token. The optional
ReferenceType element contains a URI that specifies the token type. The SerialNo element contains a unique identifier for the token. The ReferenceToken element is extensible. Additional elements and attributes are allowed in the ReferenceToken element, and additional attributes are allowed in the ReferenceDigest, ReferenceType and SerialNo elements if they do not modify the semantics of the WS-Federation specification.
The FederationID Element
The FederationID element can be included in an RequestSecurityToken or RequestSecurityTokenResponse in order to indicate which federation is being used. The structure of this element is as follows:
<fed:FederationID ...>xs:anyURI</fed:FederationID>
The FederationID element contains a URI that identifies the federation. The FederationID element is extensible. It can contian additional attributes that do not modify the semantics of the WS-Federation specification.
The RequestProofToken Element
The RequestProofToken element is used to extract a token to pass to a relying party that does not have the ability to get the session key. It has the following structure:
<fed:RequestProofToken ...>
...
</fed:RequestProofToken>
The RequestProofToken element is extensible. Additional elements and attributes can be
included in the RequestProofToken element if they do not modify the semantics
of the WS-Federation specification.
The ClientPseudonym Element
Pseudonym services may optionally support the ClientPseudonym element. The ClientPseudonym element is used to request an ad hoc pseudonym and is echoed in the RSTR. It has the following structure:
<fed:ClientPseudonym ...>
<fed:PPID ...>xs:string</fed:PPID>
<fed:DisplayName ...>xs:string</fed:DisplayName>
<fed:Email ...>xs:string</fed:Email>
...
</fed:ClientPseudonym>
The PPID element contains a private personal identifier. The DisplayName element
contains a display value. The Email element contains an E-mail address. The ClientPseudonym element is extensible. Additional elements and attributes can be included in the ClientPseudonym, PPID, DisplayName and Email elements if they do not modify the semantics of the WS-Federation specification.
The Freshness Element
The Freshness element is used to specify how long to re-use cached credentials. It has the
following structure:
<fed:Freshness AllowCache="xs:boolean" ...>
xs:unsignedint
</fed:Freshness>
The integer value of the Freshness element is used to specify the number of minutes to allow the re-use of cached credentials. The Freshness element is extensible. Additional attributes are allowed to be included in the Freshness element if they do not modify the semantics of the
WS-Federation specification.
Authorization in WS-Federation
One type of Security Token Service supported by WS-Federation is an authorization service.
WS-Federation includes an authorization model and extensions to the WS-Trust specification that are created for the purposes of supporting powerful authorization expressions. An authorization service uses two tables to make authorization decisions. The first of these tables is the requirement table that specifies the claims that are required to access target
services. The second table is the claim table and is used to store the sets of claims that requestors have provided, after processing with other context information and applicable policies.
The auth:AdditionalContext Element
The auth:AdditionalContext element is used for including arbitrary authorization context data in the RST and RSTR. It has the following structure:
<wst:RequestSecurityToken>
...
<auth:AdditionalContext ...>
<auth:ContextItem Name="xs:anyURI" Scope="xs:anyURI" ...>
element.</auth:AdditionalContext>
...
</wst:RequestSecurityToken>
The ContextItem element contains is used to specify names and values for additional context properties. The Name attribute value is a URI that indicates what type of context property is being specified. The Scope element is optional and is used to indicate a scope for the property.
A Dialect for Interoperable Claim Expression
A dialect is included in the WS-Federation specification for the interoperable specification of claims. A RequestSecurityToken element with a set of claims that uses this dialect has the following
structure:
<wst:RequestSecurityToken>
...
<wst:Claims Dialect=http://schemas.xmlsoap.org/ws/2006/12/authorization/authclaims>
<auth:ClaimType Uri="xs:anyURI" Optional="xs:boolean">
<auth:Value>...</auth:Value>
</auth:ClaimType>
</wst:Claims>
...
</wst:RequestSecurityToken>
The ClaimType element is used to specify an individual claim. The Uri attribute is used to indicate the claim type. The Optional attribute is used to specify whether a claim is optional or mandatory. The Value element is optional and is used to indicate a string value for the claimbeing specified. The ClaimType element is extensible. Additional elements and attributes are allowed to be contained in the ClaimType element if they do not modify the semantics of the WS-Federation specification.
No comments:
Post a Comment