I know there have already been many articles about how to make SharePoint work with ADFS 2.0, like the one from SPIdentity team blog and the one by Eric Kraus. What I want to do is to create a simple IP-STS and make use of it in SharePoint 2010 rather than ADFS 2.0, so that when I show customers the whole idea of claim based authentication in SharePoint 2010, I can focus on SharePoint itself instead of introducing them how ADFS 2.0 works.
So here comes the whole story of what I have done.
First of all, I created a very simple IP-STS web site based on the Asp.Net Security Token Service Web Site template which came from WIF SDK. I didn’t even make any change to its out-of-box code. The only thing I added was the certificate information in web.config.
A normal IP-STS usually needs two certs, signing cert and encrypting cert. The encrypting cert is used to encrypt the security token issued by the STS. In web.config of the STS web site, they are defined by the following app settings.
<add key=“IssuerName” value=“SimpleSTS“/>
<add key=“SigningCertificateName” value=“CN=DevBox“/>
<add key=“EncryptingCertificateName” value=“CN=DevBox“/>
To make things simple, I used a single cert here for both signing and encrypting. If you want to build a production level STS, you should use different certs for them.
To make sure the IP-STS works normally, I also built a simple Asp.Net web site to use its claims. The Url of my STS is: https://devbox/simplests/.
Make use of my IP-STS in SharePoint 2010
I used the following PowerShell commands to register my IP-STS as a trusted identity provider in SharePoint 2010. They are almost the same with the commands used in ADFS 2.0 samples.
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\signing.cer”)
$map1 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” –SameAsIncoming
$map2=New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” –SameAsIncoming
$ap=New-SPTrustedIdentityTokenIssuer -Name “SimplePassiveSTS” -Description “A simple Asp.Net STS on DevBox.” –Realm $realm -ClaimsMappings $map1,$map2 -ImportTrustCertificate $cert -SignInUrl “https://devbox/SimpleSTS/default.aspx” -IdentifierClaim $map1.InputClaimType
The default Asp.Net STS template generates the following two types of claims.
The first one cannot be mapped in SharePoint 2010 because it is a reserved claim type. That is why I modified the output claims of my STS and used the very common emailaddress type.
Another thing worth mentioning is the $realm. This field is used by STS to determine the ReplayToAddress of the Relying Party. In ADFS 2.0 samples, usually this field was set to: $realm = “urn:” + $env:ComputerName + “:Geneva”. I believe ADFS 2.0 knows how to handle this realm if it comes from SharePoint 2010. My STS does not understand the realm like this. So I simply used http://claimauthweb/_trust/default.aspx for realm so that my STS can reply to this address directly.
http://claimauthweb/ was an existing SharePoint web app with Claim mode authentication enabled. Now I can simply choose to use the trusted identity provider I registered in Central Administration.
Now everything looks good. When I browse to http://claimauthweb, I can see the following sign-in options.
Guess what will happen if I choose SimplePassiveSTS? Can I pass the authentication and access the SharePoint site? The answer will in the Part 2 of this series.