WS-Federation 1.1 completes the WS-* Security Stack
How does WS-Federation relate to the WS-Trust specification that was recently ratified as an OASIS standard?
WS-Trust lays the foundation for federation by enabling SecurityToken Services (STS) to broker trust between resource and identity providers; it provides an application-independent protocol for requesting, issuing, renewing and validating security tokens.
WS-Federation breathes life into the federated relationships envisioned by WS-Trust. WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model. Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.
Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.
Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.
Keith Brown said,
May 3, 2007 @ 8:17 am
Is WS-Fed really required to get auto deprovisioning? Seems to me that as soon as you use an “STS to broker trust between resource and identity providers”, you should get the benefit of auto deprovisioning.
des said,
May 3, 2007 @ 7:03 pm
Good point Keith. Strictly speaking if an external user only authenticates using a token from an STS in another security realm, the auto deprovisioning is a natural consequence. My statement applies more to the concept of Federated Identity in general than it does to WS-Federation improvements to WS-Trust alone. That said, I have seen RPs that do not fully believe in federation and maintain passwords as well. This approach is helpful in network segmentation, but does not provide the auto deprovisioning benefit.
des on Federated Identity … less is more » Blog Archive » WS-Federation 1.1 goes to OASIS said,
May 23, 2007 @ 11:01 am
[...] des on Federated Identity … less is more « What is Federated Identity? WS-Federation 1.1 completes the WS-* Security Stack [...]
Pedro Felix said,
May 30, 2007 @ 7:58 am
I’ve some question regarding the metadata framework present in the WS-Federation specification:
1) Why does the requester needs the federation metadata, except for ? Isn’t all the other information needed by the requester present in the service’s policy, namely the token issuer endpoint and the required claims (contained inside a policy assertion)?
2) Who are the consumers of the federation metadata exposed by the RP? Is it only the requester? Is it the IP? Can’t the information can be stated inside the element on the assertion? The same applies to the .
I can understand the importance of the federation metadata exposed by the IPs, but not the metadata exposed by the RP.
Don Schmidt said,
May 30, 2007 @ 11:47 pm
Pedro,
There seem to be some words that got dropped in your comments. I will do my best to fill in the blanks and answer your questions.
First, it is useful to point out that there is not always a complete separation between the IP and RP service provider roles. For example, an IP is temporarily in the Relying Party role when it receives a request to issue a token and it must authenticate the requestor.
Second, WS-SecurityPolicy allows service providers, both IPs and RPs, to publish their requirements. However, WS-SecurityPolicy does not provide a mechanism for them to publish their capabilities. One of the goals of federation metadata is to allow service providers to publish their capabilitiies.
fed:TokenTypesOffered and fed:URINamedClaimTypesOffered are examples of “capability” metatdata statements. Your observation is correct that they are useful for IPs rather than RPs. However, there are “requirement” metadata statements that are useful for RPs (or IPs when they are the Relying Party role). fed:TokenKeyTransferKeyInfo and fed:SingleSignoutNotificationEndpoint are examples.
One use case for federatin metadata enables federation partners, IPs and RPs, to automate their configurations [about each other]. We wanted to address this because customers have complained about the manual mechanism for configuring federation partners in ADFSv1 and other first generation WS-Federation products. Automating this configuration process can be facilitated if IPs publish capability statements (e.g. fed:TokenSigningKeyInfo and fed:SingleSignoutSubscriptionEnpoint) and RPs publish requirement statements (e.g. fed:TokenKeyTransferKeyInfo and fed:SingleSignoutNotificationEndpoint).
Another use case involves automating the ability of requestors — especially InfoCard style clients, such as, CardSpace — to determine which IPs can satisfy RP requirements. RPs can express their token type and claim type requirements in WS-SecurityPolicy. If RPs do not specify specific IPs for issuing tokens, clients must match up IPs and RPs based on token and claim types. This requires that IPs publish their capabilities using metadata statements (e.g. fed:TokenTypesOffered and fed:URINamedClaimTypesOffered) since their is no mechanism for them to do this in WS-SecurityPolicy.
There is some overlap between WS-Federation metadata statements and WS-SecurityPolicy assertions. fed:TokenIssuerName and fed:TokenIssuerEndpoint correspond to sp:IssuerName and sp:Issuer, respectively. However, the WS-Federation metatdata statements can be repeated in separate sections of the metadata document (as specified by FederationID) to indicate different IPs that are trusted in different federations in which the RP participates.
Pedro Felix said,
May 31, 2007 @ 3:51 am
Hello,
First of all, thanks for your reply.
Unfortunately, I didn’t notice that all the words with angle brackets surrounding them (corresponding to metadata elements) were removed from the comment (an anti-XSS measure I assume).
I reproduce above parts of my comment, with angle brackes replaced by double quotes:
1) Why does the requester needs the federation metadata, except for the “SingleSignOutElement”? Isn’t all the other information needed by the requester present in the service’s policy, namely the token issuer endpoint and the required claims (contained inside a policy assertion)?
2) Who are the consumers of the federation metadata exposed by the RP? Is it only the requester? Is it the IP? Can’t the “TokenIssuerEndpoint” information be stated inside the “Issuer” element on the “IssuedToken” assertion? The same applies to the “TokenKeyTransferKeyInfo”.
Regarding your comments:
1) I understand and agree that an IP can also have the RP role: it will be the producer of tokens but also the consumer. When I refer to an RP it does not have to be the final RP in the chain, it just a token consumer.
2) I also understand that the WS-SecurityPolicy assertions do not provide a way to express capabilities. However, I think that the policy is the right place to express capabilities. So, shouldn’t the WS-SecurityPolicy be extended with this information (e.g “SingleSignoutNotificationEndpoint”)?
3) I agree with you that the “SingleSignoutNotificationEndpoint” capability exposed by RPs is useful to requesters. But I also think that it is the only federation metadata information exposed by a RP that is relevant to the requester. For example, the “TokenIssuerEndpoint” is completely redundant, since it is in the RP’s policy.
4) The “TokenKeyTransferKeyInfo” can be useful if the IP wishes to provision the RP key during the federation setup. However, this key can also be present in the “AppliesTo” element present in the RP policy and inserted in the RST message sent to the IP.
5) Regarding the discovery of IPs by a requestor, I think that this does not solve the problem completely. First, using “information cards” (IC), the requester already knows what are the claims and token types exposed by some IPs. This information would be useful for intermediary IPs (IPs that receive tokens from IPs and issue tokens to other IPs or RPs). For example, this could enable “bidireccional” construction of policy chains: construction of policy chains starting at both the requestor and the final RP and running both ways until a complete chain is established. However, for this to be possible, the IPs would have to expose the capabilities of other IPs.
I would like to discuss this subject further; however this comment is getting rather long.
Once again, thanks for your reply and sorry for the long comment.
Don Schmidt said,
June 2, 2007 @ 9:18 am
Pedro,
Thanks for clarifying your questions. It appears I understood your intention and answered correctly.
Regarding your revised question 3, I agree there is some overlap between Federation Metadata and WS-SecurityPolicy with respect to an RP’s requirements. We discussed this while writing the spec and concluded that metadata, such as “TokenIssuerEndpoint” is not completely redundant, as I stated in my original response. We have learned from customer experience that many RPs and IPs participate in different federations concurrently. The Federation Metadata document can be sectioned to facilitate publishing the RP requirements, as well as the IP capabilities, that are unique to a particular federation.
Regarding your question 5, the chain if IPs you describe is one of the reasons why publishing an IP’s capabilities is usefl to InfoCard clients. As you implied, the act of provisioning an InfoCard client by managed-card providers will “train” the client with respect to that IP’s capabilities. Since a chain of managed-card providers is not supported in some first generation clients, the correct chain of subsequent IPs can be discovered using WS-MetadataExchange to retrieve WS-SecurityPolicy and Federation Metadata documents.
Further, we are still working through the client provisioning and update process for managed-card providers. Publishing an IP’s capabilities may play a role here as well.
Pedro Felix said,
June 4, 2007 @ 3:56 am
Don,
Yes, you´ve answered my questions correctly. Thanks!
The usefulness of all the metadata published by an RP is not completely clear to me, since most of it is also on the RP policy. However I agree that there might be some advantages in publishing these requirements in a separate federation metadata document.
I’ve also published a post on my blog with some problems and ideas about the policy chain discovery problem: http://www.cc.isel.ipl.pt/CS/blogs/pfelix/archive/2007/06/04/notes-on-the-policy-chain-discovery-problem.aspx
Any comments on this post would be highly appreciated.
Pedro Felix said,
June 26, 2007 @ 12:08 pm
Hello again. Just one more question: is the policy chain bulding process a concern for the OASIS WSFED TC?
In small scale scenarios (few STS level) and without policy alternatives this process is rather easy to acomplish: just follow the policy references from the RP policy until a local IP policy. However, in large scale scenarios (multiple STSs levels) with multiple policy alternatives, the policy chain building is not straightforward: the policy of the RP and intermediary STS can have a large number of alternatives. Does the WS-Federation target these scenarios? Is this a concern for the WSFED TC?