Earlier this morning the Geneva (WIF/ADFS) Product Team announced a CTP for supporting the SAML protocol within WIF. WIF has supported SAML tokens since it's inception, however it hasn't supported the SAML protocol until now. According to the team:
This WIF extension allows .NET developers to easily create claims-based SP-Lite compliant Service Provider applications that use SAML 2.0 conformant identity providers such as AD FS 2.0.
This is the first I've seen this CTP, so I decided to jump into the Quick Start solution to get a feel for what's going on. Here is the solution hierarchy:
There isn't much to it. We have the sample identity provider that generates a token for us, a relying party application (service provider), and a utilities project to help with some sample-related duties.
In most cases, we really only need to worry about the Service Provider, as the IdP probably already exists. I think creating an IdP using this framework is for a different post.
If we consider that WIF mostly works via configuration changes to the web.config, it stands to reason that the SAML extensions will too. Lets take a look at the web.config file.
There are three new things in the web.config that are different from a default-configured WIF application.
First we see a new configSection declaration:
<section name="microsoft.identityModel.saml" type="Microsoft.IdentityModel.Web.Configuration.MicrosoftIdentityModelSamlSection, Microsoft.IdentityModel.Protocols"/>
This creates a new configuration section called microsoft.identityModel.saml.
Interestingly, this doesn't actually contain much. Just pointers to metadata:
<microsoft.identityModel.saml metadata="bin\App_Data\serviceprovider.xml">
<identityProviders>
<metadata file="bin\App_Data\identityprovider.xml"/>
</identityProviders>
</microsoft.identityModel.saml>
Now this is a step away from WIF-ness. These metadata documents are consumed by the extension. They contain certificates and endpoint references:
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:6010/IdentityProvider/saml/redirect/sso"/>
I can see some extensibility options here.
Finally, an HTTP Module is added to handle the token response:
<add name="Saml2AuthenticationModule" type="Microsoft.IdentityModel.Web.Saml2AuthenticationModule"/>
This module works similarly to the WSFederationAuthenticationModule used by WIF out of the box.
It then uses the SessionAuthenticationModule to handle session creation and management, which is the same module used by WIF.
As you start digging through the rest of the project, there isn't actually anything too surprising to see. The default.aspx page just grabs a claim from the IClaimsidentity object and adds a control used by the sample to display SAML data. There is a signout button though which calls the following line of code:
Saml2AuthenticationModule.Current.SignOut( "~/Login.aspx" );
In the Login.aspx page there is a sign in button that calls a similar line of code:
Saml2AuthenticationModule.Current.SignIn( "~/Default.aspx" );
All in all, this SAML protocol extension seems to making federating with a SAML IdP fairly simple and straightforward.