Contents tagged with WS-Federation
WIF is an excellent framework that allows you to develop an STS in just a few minutes if you know exactly what you are doing of course :). In my role as consultant and architect in Tellago, I went through several projects in which some level of customization was required at wire level to accomplish some interoperability between a STS built with WIF and existing federation solutions like ADFS 1.x and OpenSSO.
The Federation Authentication Module (FAM) shipped as part of WIF protects by the default the session cookies from being tampered with in passive scenarios using DPAPI. As I mentioned in the past, this technique simplifies a lot the initial deployment for the whole solution as nothing extra needs to configured, the automatically generated DPAPI key is used to protect the cookies, so this might be reason to have that as default protection mechanism in WSE, WCF and now WIF.
I was wondering these days what would be the point in using WS-Passive when there is another simple sign-on solution, OpenID, that works really well and it’s getting a great adoption in the community. I can not say the same about WS-Passive, I haven’t seen any concrete implementation yet (For instance, Microsoft is planning to release a first implementation as part of the WIF framework before the end of this year).
When SAML is used in conjunction with WS-Security, only an small piece of the token is encrypted, the proof key for the relying party. The rest of the token goes in plain text, that also includes the user's claims.
<saml:Conditions NotBefore="2009-02-24T19:48:20.500Z" NotOnOrAfter="2009-02-24T19:53:20.500Z"></saml:Conditions>
<saml:Attribute AttributeName="displayName" AttributeNamespace="http://schemas.microsoft.com/xsi/2005/05/role">
<saml:AttributeValue>John Foo</saml:AttributeValue> <--Attribute value-->
Knowing this, you should never include sensitive information as claims in a SAML token. This is also related to the identity law #2, "Minimal Disclosure for a Constrained Use". The Identity provider should only disclose the least amount of identifiying information for executing the operation on the relying party.
Some examples are,
- A winery only needs to know whether the customer is in a legal age for buying alcohol according to the law, a claim like "over21" should be enough for that purpose, there is not need to know the customer birth date at all.
- An online store that sells products does not necessary need to know the number of every credit card owned by a customer, a friendly name representing the card and optionally the available balance could be enough for completing a purchase.
SAML 2.0 introduces the concept of "encrypted attribute", which clearly states its purpose, encrypt individual assertions in a SAML token. In this way, a token can now carry the encrypted proof key and optionally one or more encrypted assertions with sensitive information.
You can take a look at this page for more information about the differences between SAML 1.1 and 2.0.
Geneva Framework Beta 1 already implements a subset of SAML 2.0, however, it looks like this feature has been left out in the current release. Not sure either whether this feature will be included as part of the final release (Last quarter of 2009). I created a post in the forums some time ago, I haven't received any feedback yet.
OpenID and OAuth are today excellent solutions for "Single Sign On" (SSO) and "Authorization Delegation" respectively. They are, however, based on Http Redirections and therefore, tied to passive clients or commonly called web browsers.
An interesting research was made by google some time ago, it can be found here. After reading that article, it looks like they could not get rid of a browser at all :(.
If that does not work for you, another solution could be WS-Federation Active Profile.
"SSO" is an inherent feature of WS-Federation, not doubt about it.
"Authorization Delegation" can also be emulated with a combination of "SSO" and authorization claims. In this scenario, we always give our credentials to an identity provider we trust, there is no need to give away our credentials to any site or service involved in a transaction. The authorization claims also represent fine-granular permissions of what we are allowed to do on the service side, and again, they can provided by identity provider itself or a resource STS. I discussed this approach in my last post, "Addressing Authorization with OAuth or the .NET Access Control Service", the resource STS in this case would be the ACS service.