Claims Based Authentication with SharePoint 2010

Claims Based Authentication with SharePoint 2010

Architecture

Overview The claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 is built upon Windows Identity Foundation (WIF), formerly code-named "Geneva" Framework Beta. Claims-based identity is an identity model in SharePoint Foundation 2010 and SharePoint Server 2010 that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications. When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea is that an external identity system is configured to give your application all the information it needs about the user with each request, along with cryptographic assurance that the identity data you receive comes from a trusted source. Under this model, single sign-on is much easier to achieve.

Figure 1: Issuers, security tokens, and applications

Figure 2: ADFS functions

Steps

1. Create a local server instance with W2K8 R2, Sql Server and set it up as a domain controller
2. Install ADFS 2.0 RC
3. Open the command prompt and browse to the ADFS installation folder cd "%programfiles%\Active Directory Federation Services 2.0"
4. Configure ADFS with your database instance (instead of the default internal database). From the command prompt, type the following and fill in your details:

   FsConfigWizard.exe -sqlhost: -sqlinstance: -servacct: -servpass: [-dropdb]

   Parameter	Description
   -sqlhost	Sets the value.
   	Specifies the name of the computer that is running an instance of SQL Server for use with AD FS 2.0. For example, if the local computer is to be specified, type localhost here.
   -sqlinstance	Sets the value.
   	Specifies the name of the SQL Server database instance to be used as the database. For example, to specify that a default Structured Query Language (SQL) instance that AD FS 2.0 Setup creates is to be used, type SQLEXPRESS here.
   -servacct	Sets the value.
   	Specifies the name of the Active Directory service account to use for running the AD FS 2.0 service. For example, to specify that the Network Service account for the Contoso domain be used, type CONTOSO\NetworkService here.
   -servpass	Sets the value.
   	Specifies the password text for the account set using the -servacct parameter.
   -dropdb	(Optional.) If this parameter is specified, it deletes or overwrites any existing database if one is found to exist. If this parameter is omitted, and an existing AD FS 2.0 database is located it will be used. If no parameter is specified and no existing database is located, the database will be created as needed. To create the database, AD FS 2.0 uses the hosted SQL Server instance that is set using the -sqlhost and -sqlinstance parameters.

5. Create a claims-enabled SharePoint web application. Click “Create new Web Application” in Central Administration and select the “Claims Based Authentication” radio-button in the Authentication section. Create the base site collection after this. 

6. (Optional) Create and deploy the claims checker webpart. You can download the WSP from here. You can download the sourcecode from here.

7. Launch ADFS 2 and validate the certificate, which should be the same certificate bound to the default web site. Make any changes necessary to ensure the Service Communications certificate and SSL binding in IIS is fully operational.

8. As a test, you should be able to browse to https:///FederationMetadata/2007-06/federationmetadata.xml

9. Now, export your Token-Signing Certificate to the c:\ drive. The quickest way to do this is to right-click the certificate in the ADFS 2.0 Management Console and select “View Certificate…”. Then, navigate to the Details tab and click the button labeled Copy to File… This will launch the Certificate Export Wizard. Follow the wizard to export the certificate as a DER encoded binary X.509 (.CER) file. For simplicity, I recommend saving the certificate to the C:\ drive. You will need this file in the following PowerShell script.

10. Add ADFS 2.0 as a Federated Identity Provider in SharePoint $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType Configure Role Powershell Script

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer")
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$realm = "urn:" + $env:ComputerName + ":adfs"
$signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType 

HINT: You can copy and paste the above PowerShell commands into a text file. Save the text file with the .ps1 extension and you will be able to execute the file from within PowerShell. Be sure to launch “SharePoint 2010 Management Shell” as this will load all the SharePoint related extensions. 11. You should now be able add the Federated Identity Provider in Central Administration. Navigate to Web Applications Management, highlight the web application, and click the Authentication Providers button in the ribbon. You should now see your new provider in the Federated Identity Provider section of the Edit Authentication window

12. At this point, if you browse to your claims-enabled SharePoint site you’ll find a new screen where you need to specify what Identity Provider to use for access. This happens because we have both our Federated Identity Provider and Windows Authentication enabled for this zone. It should be noted that this screen can be customized with logic to automatically determine the correct provider based on the client IP address (for example). For now, we need to stick with Windows Authentication because ADFS 2.0 isn’t configured yet to work with SharePoint.

13. There appear to be issues getting claims-enabled web applications that have both a custom Federated Identity Provider and standard Windows Authentication provider enabled. Therefore delete and create the web application again.