Have you ever noticed the security paradox in computers? Most people will agree that managing Active Directory or LDAP directories is an administrative task. Not necessarily the password resets and account create (those tend to get pushed to the help desk), but the installation, configuration and general maintenance of these vital data stores is performed by the top-of-the-heap admin. (Rightly so!)
However, if the authentication provider is not one of these, say an ASP.NET Membership provider (FBA), then it usually falls to the developer to configure the solution. It seems short sighted to me that the person charged with monitoring the system would wash their hands of the technology used to secure it! But, I’m not here today to change this activity. No, I am writing about a wonderful little utility that developers and admins alike can use to get up to speed on the new claims-based identity world!
First, a little background. To setup claims authentication with SharePoint, you need to follow the directions on TechNet: Configure authentication using a SAML security token (SharePoint Server 2010). The big stumbling point for those just getting started – where do I find a Security Token Service Web application? The answer is either ADFS2 or the WIF SDK. Well, now you have a third, and much easier option - SelfSTS.
SelfSTS is a security token service that is designed to issue tokens without a lot of configuration. For a full explanation, refer to Vittorio’s blog post. (If you are not subscribed to Vittorio’s blog, then you are not serious about claims auth!) To get SelfSTS working with SharePoint, there are a few little tweaks required outside of the steps laid out by TechNet and Vittorio. The steps below are copied and adjusted from the TechNet directions.
- Extract SelfSTS and run the executable from the bin\Release directory.
- Save the X509 Certificate that SelfSTS is using
- In the browser, navigate to the federation metadata page. (Be sure to start SelfSTS first. Otherwise, you will get a DNS error.) Hint: You can copy the url of the page from the SelfSTS UI. Click the "C" next to the link.
- In the metadata page, look for a tag named X509Certificate. Copy the inner text from any of these tags and paste it into Notepad.
- Save the file in Notepad. I put mine in the SelfSTS bin\Release folder with the name SelfSTS.cer
- In the SharePoint Management Console (PowerShell), read the certificate into a variable.
$cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")
- Map the claim that SelfSTS provides to one that is understood by SharePoint
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
- The Realm setting is used by the STS to identify the source of the authentication request. In ADFS2, there is a user interface for mapping this identifier with the url of the application. However, SelfSTS does not have such a UI. Instead, it will automatically redirect to the value provided as the realm. So, this must be the url of the SharePoint claim service.
$realm = "http://[WebApplicationUrl]/_trust/"
- You will need to tell SharePoint the url of the identity provider. This is the endpoint in SelfSTS. (I’ve listed the default value below.)
$signinurl = "http://localhost:8000/STS/Issue/"
- Now, the trusted login provider can be created as shown in the TechNet article.
New-SPTrustedIdentityTokenIssuer -Name
"SelfSTS" -Description "SelfSTS sample" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
Upon completion of these steps, the SelfSTS provider will be available for selection in the Trusted Identity Provider section when creating a new Web Application or modifying the Authentication Providers of an existing claims-based web application.
Before attempting to login to a site collection using SelfSTS, there are a few other items to address. The token signing certificate used by SelfSTS must be trusted by SharePoint. This is accomplished by the New-SPTrustedRootAuthority cmdlet in PowerShell, or via the Manage Trust link in the Security section of Central Administration. Also, be sure to grant permissions to the account provided by SelfSTS (or the all users account).
Again, the key differences when using SelfSTS is the Realm property, and that https is not required. (You are not leaving the box, so no need to incur that overhead.) Lastly, I want to point out that THIS IS FOR DEVELOPMENT PURPOSES ONLY. You should never use SelfSTS in production.
Update: Works fine under Windows 7.