The current project I’m working on is a Identity Management Solution for a client. We’re working with WIF (as you might have noticed in my previous posts) and SPML v2. I’ve been beating my head against a wall for the last few days because we had all kind of problems to get the Identity Delegation scenario working. Eventually it was a small thing which caused all kinds of problems, but I’ll elaborate on that in a different post.
One thing that I found frustrating is the lack of documentation for WIF and especially that it’s difficult that way to configure the identity related stuff correctly. We figured out now what all the configuration items in the microsoft.IdentityModel section mean, so I’m sharing it here so that other people starting with WIF don’t have the same giant learning curve we had ;-).
For a consuming application, the following is a common configuration when using an active STS (note that we use the .NET 3.5 targeted assemblies):
<microsoft.identityModel> <service saveBootstrapTokens="true"> <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35"> <trustedIssuers> <add thumbprint="9dbc8c485022a10788832ab285a6281fe18a22de" name="CN=sts" /> </trustedIssuers> </issuerNameRegistry> <audienceUris> <add value="http://frontend" /> </audienceUris> <securityTokenHandlers></securityTokenHandlers> <federatedAuthentication> <wsFederation passiveRedirectEnabled="false" issuer="https://sts/SecurityTokenService.svc" realm="http://frontend" requireHttps="false" /> <cookieHandler requireSsl="false" /> </federatedAuthentication> <serviceCertificate> <certificateReference x509FindType="FindByThumbprint" findValue="4fa9361d1ddda6e8847313a56ab96412dd40f13b" storeLocation="LocalMachine" storeName="My"/> </serviceCertificate> </service> </microsoft.identityModel>
Now what does all this mean and what is it for?
This means that when WIF makes an ClaimsIdentity from a received SecurityToken, that the property BootstrapToken of the ClaimsIdentity will be the actual token received. I wish I had found about this earlier.
This section indicates which sts you trust. Here you add the certificate(s) which are used to sign the tokens you receive from the STS
This section is used to check whether the received information from the STS is applicable to you as the calling application. It should match the AppliesTo property which you set when you issue a RequestForSecurityToken to your STS.
In this section you can remove the default handlers and add your own token handlers. Note 1: Don’t clear the collection, because most of them are necessary. If you want to use a custom, then only remove the default of the type you want to add. Note 2: Be very careful with what you do here. One wrong decision here has cost us a lot of hours of bug hunting.
This section contains information to determine if you are using an active or passive scenario. When you have a passive scenario (when the browser handles the redirects etcetera for you) then you set passiveRedirectEnabled=”true”. You have to make sure then that the correct issuer and realm and other related attributes are set.
The cookieHandler requireSsl attribute indicates whether the written session cookie requires SSL. When you are working on a non-ssl connection and you forget to set this to false, your cookies won’t be preserved over postbacks.
This section was the least clear to me when starting out. It is for defining which certificate should be used to decrypt the incoming SecurityToken.
When you setup these values correctly, you should get up and running pretty quickly. This post is just for making clear what each section of the configuration is for. To get an overview of all steps to do for getting up and running using an active STS, please read my previous post about making a web application use an active STS.
I hope this helps some of you to save some time when configuring WIF.