Export (0) Print
Expand All

Configure authentication using a SAML security token (SharePoint Server 2010)

SharePoint 2010
 

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

Topic Last Modified: 2013-01-21

The procedures in this article explain how to configure authentication using a Security Assertion Markup Language (SAML) security token for a Microsoft SharePoint Server 2010 claims-based Web application.

SAML sign-in is typically used in enterprise federation scenarios, for example, to provide access to a business partner. SAML sign-in is also deployed to provide access to internal users whose accounts reside in a domain that is not part of the forest that contains SharePoint Server 2010.

Before you configure authentication using a SAML security token for a SharePoint Server 2010 claims-based Web application, you must configure an identity provider that supports WS-Federation, such as Active Directory Federation Services (AD FS) 2.0. For information about configuring a server to run AD FS 2.0, see the AD FS 2.0 Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=191723).

In this article:

Perform the following procedures to use Windows PowerShell to configure a SharePoint claims-based Web application.

To configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create an x509Certificate2 object, as shown in the following example:

    $cert = New-Object
    System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")
    
  6. Create a claim type mapping to use in your trusted authentication provider, as shown in the following example:

    New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
    
  7. Create a trusted login provider by first creating a value for the realm parameter, as shown in the following example:

    $realm = "urn:" + $env:ComputerName + ":domain-int"
    
  8. Create a value for the signinurl parameter that points to the Security Token Service Web application, as shown in the following example:

    $signinurl = "https://test-2/FederationPassive/"
    
  9. Create the trusted login provider, using the same IdentifierClaim value as in a claim mapping ($map1.InputClaimType), as shown in the following example:

    $ap = New-SPTrustedIdentityTokenIssuer -Name
    "WIF" -Description "Windows® Identity Foundation" -Realm
    $realm -ImportTrustCertificate $cert
    -ClaimsMappings $map1[,$map2..] -SignInUrl
    $signinurl -IdentifierClaim $map1.InputClaimType
    
  10. Create a Web application by first creating a value for the application pool account (for the current user), as shown in the following example:

    $account = "DOMAIN\" + $env:UserName
    
    noteNote
    The application pool account must be a managed account. To create a managed account, use New-SPManagedAccount.
  11. Create a value for the Web application URL ($webappurl = "https://" + $env:ComputerName), as shown in the following example:

    $wa = New-SPWebApplication -name "Claims WIF"
    -SecureSocketsLayer -ApplicationPool "SharePoint SSL"
    -ApplicationPoolAccount $account -Url $webappurl -Port 443
    -AuthenticationProvider $ap
    
  12. Create a site by first creating a claim object, as shown in the following example:

    $claim = New-SPClaimsPrincipal
    -TrustedIdentityTokenIssuerr $ap -Identity
    $env:UserName
    
    
  13. Create a site, as shown in the following example:

    $site = New-SPSite $webappurl -OwnerAlias
    $claim.ToEncodedString() -template "STS#0"
    

Use the procedure in this section to configure a relying-party STS Web application.

To configure a Relying Party STS (RP-STS) Web application
  1. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  2. In the left pane, expand Policy, and select Relying Parties.

  3. In the right pane, click Add Relying Party. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  4. On the first page of the wizard, click Start.

  5. Select Enter relying party configuration manually, and click Next.

  6. Type a relying party name and click Next.

  7. Make sure Active Directory Federation Services (AD FS) 2.0 Server Profile is selected, and click Next.

  8. Do not use an encryption certificate. Click Next.

  9. Select Enable support for Web-browser-based identity federation.

  10. Type the name of the Web application URL, and append /_trust/ (for example: https://servername/_trust/). Click Next.

  11. Type the name of an identifier (for example: urn:COMPUTERNAME:Geneva), and click Add. Click Next.

  12. On the Summary page, click Next and then click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims from an LDAP Web application to SharePoint.

  13. In the left pane, expand New Rule, and select Predefined Rule.

  14. Select Create Claims from LDAP Attribute Store.

  15. In the right pane, from the Attribute Store drop-down list, select Enterprise Active Directory User Account Store.

  16. Under LDAP Attribute, select sAMAccountName.

  17. Under Outgoing Claim Type, select E-Mail Address.

  18. In the left pane, click Save.

Use the procedure in this section to establish a trust relationship with an IP-STS.

To establish a trust relationship with an IP-STS by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, establish a trust relationship, as shown in the following example:

    $waurl = "https://" + $env:ComputerName
    $title = "SAML-Claims"
    

Use the procedure in this section to export the certificate of the IP-STS with which you want to establish a trust relationship, and then copy the certificate to a location that Microsoft SharePoint Server 2010 can access.

To export the trusted IP-STS certificate by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, export the trusted IP-STS certificate, as shown in the following example:

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\geneva.cer")
    

Use the procedure in this section to define an e-mail address that will serve as a unique identifier for claims mapping. Typically, the administrator of the trusted STS will have to provide this information because only the owner of the STS knows which value in the token will be always unique for each user. Note that the administrator of the trusted STS can create a URI to represent the e-mail address.

To define a unique identifier for claims mapping by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create a mapping, as shown in the following example:

    $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
    

Use the procedure in this section to create a new authentication provider that the Web application will use.

To create a new authentication provider by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create a new authentication provider, as shown in the following example. Note that the realm is the parameter used by the trusted STS to identify a specific SharePoint farm.

    $realm = "urn:" + $env:ComputerName + ":Geneva"
    $ap = New-SPTrustedIdentityTokenIssuer -Name "Geneva" -Description "Geneva" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https:// test-2/FederationPassive/" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    

In this step, you create and configure the Web application.

To create a new SharePoint Web application and configure it to use SAML sign-in by using Windows PowerShell
  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. From the Windows PowerShell command prompt, create a new SharePoint Web application and configure it to use SAML sign-in. Note that you must replace "WebAppUrl" and "domain\admin" with the valid values.

    $wa = New-SPWebApplication -Name "SAML Sign-In" -SecureSocketsLayer -ApplicationPool "SAML Sign-In" -ApplicationPoolAccount "domain\admin" -
    Url "WebAppUrl" -Port 443 -AuthenticationProvider $ap
    
    noteNote
    You are enabling SSL, because with SAML sign-in, cookies are used as the single sign-on ticket for the user. This allows administrators to grant access to the SharePoint resources for the duration of the token without the need of re-authenticate the user. Without SSL, these cookies can be easily hijacked by a malicious user and be used to impersonate the original user.

When you have completed these procedures, create a SharePoint site and assign an owner. For information about creating a SharePoint site, see Create a site collection (SharePoint Server 2010).

To provide additional security for UNRESOLVED_TOKEN_VAL(1st_OSS_14) web applications that use SAML-based claims authentication, you can use the UNRESOLVED_TOKEN_VAL(IDFX_O15_supported_1st) token replay detection feature. Token replay protection can prevent an attacker from trying to intercept and use a user’s security token. For more information, see Replay Detection.

Use the procedure in this section to enable replay detection on a UNRESOLVED_TOKEN_VAL(1st_OSS_14) web application that is configured for SAML claims authentication.

To enable replay protection
  1. On the server running UNRESOLVED_TOKEN_VAL(1st_OSS_14), open the Internet Information Services (IIS) Manager snap-in.

  2. In the console tree of Internet Information Services (IIS) Manager, right-click the site that corresponds to the name of the web application, and then click Explore.

  3. In the folder window, double-click the Web.Config file.

  4. In the <Configuration> section, find the <microsoft.identityModel> section.

  5. Add the following as a new section to the <microsoft.identityModel> section:

    <service>
        <tokenReplayDetection enabled="true" capacity="<NumberOfTokensToBeCached>" expirationPeriod="<TokenCacheExpiration>">
    </service>
    

    in which:

    • <NumberOfTokensToBeCached> is the number of tokens to store in the token replay detection cache.

    • <TokenCacheExpiration> is the time after which a token in the replay detection cache is removed, in <hours>:<minutes>:<seconds> format.

  6. Save your changes to the Web.Config file.

For important considerations about enabling token replay protection in a load-balanced environment, see ACS Security Guidelines.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft