10.2 Configuring Access Manager as a Claims or Identity Provider and AD FS 2.0 as Relying Party or Service Provider

This section explains how to configure a setup in which an Access Manager user gets federated access to the WIF sample application or SharePoint 2010 through AD FS 2.0. This setup uses the SAML 2.0 POST profile.

10.2.1 Configuring Access Manager

NOTE:To deploy this identity federation for Access Manager 3.1 SP4 or higher, create a new contract with the “urn:oasis:names:tc:SAML:2.0:ac:classes:Password” URI and with the name password form method. Configure this contract as the default contract.

Using Metadata to Add a New Service Provider Connection

The first step in configuring Access Manager is to use the AD FS metadata to add a service provider for Access Manager.

Getting the AD FS 2.0 Metadata

  1. Access the AD FS server metadata URL at https://<<ADFS (hostname or IP)/FederationMetadata/2007-06/FederationMetadata.xml.

  2. Save the AD FS metadata file.

  3. Open the saved AD FS metadata file in Notepad, WordPad, or in any XML editor.

  4. Remove the <RoleDescriptor> tags from the metadata. For example, remove the following tags:

    <RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration=http://..................... ……> ……….</RoleDescriptor>

      <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration=http://.....  ………> </RoleDescriptor>

  5. Save the changes.

Using the Metadata to Add a New Service Provider Connection

  1. In the Access Manager Administration Console, click Devices > Identity Server > Edit > SAML 2.0.

  2. Click New > Add Service Provider.

  3. In the Name field, specify a name by which you want to refer to the provider.

  4. Select Metadata Text from the Source list.

  5. Paste the copied AD FS metadata that you saved in Step 5 into the Text field.

  6. Click Next > Finish.

  7. Update the Identity Server.

Adding an AD FS Server Trusted Certificate

  1. Download the certificate authority (CA) certificate from the AD FS server.

  2. In the Access Manager Administration Console, click Security > Certificates > Trusted Roots.

  3. Click Import.

  4. Specify a name for the certificate and browse for the ADFS certificate.

  5. Click OK.

  6. Click Uploaded AD FS CA.

  7. Click Add to Trusted Store and select config store.

  8. Update the Identity Server.

Creating an Attribute Set in Access Manager

  1. In the Access Manager Administration Console, click Devices > Identity Servers > Shared Settings > Attribute Sets > click New.

  2. Provide the attribute set name as adfs-attributes.

  3. Click Next with the default selections.

  4. In the Create Attribute Set section, click New.

  5. Select ldapattribute mail from the Local Attribute list.

  6. Specify emailaddress in the Remote attribute field.

  7. Select http://schemas.xmlsoap.org/ws/2008/06/identity/claims/ from the Remote namespace list.

  8. Click OK.

  9. Click New.

  10. Select All Roles from the Local Attribute list.

  11. Specify roles in the Remote Attribute field.

  12. Select http://schemas.xmlsoap.org/ws/2008/06/identity/claims/ from the Remote namespace list.

  13. Click OK.

  14. Update the Identity Server.

Configuring the Service Provider in Access Manager

  1. In the Access Manager Administration Console, select the ADFS service provider in the SAML 2.0 tab.

  2. Click Authentication Response.

  3. Select Binding to POST.

  4. Specify the name identifier format default value and select unspecified along with the defaults.

  5. Click Attributes.

  6. Select adfs-attributes from the Attribute Set list.

  7. Select the required attributes to be sent with authentication. For example, the mail and cn attributes.

  8. Click OK.

  9. Update the Identity Server.

Exporting the Identity Provider Metadata to a File

Access https://<<Identity server IP / dns name>>:8443/nidp/saml2/metadata in a browser and save the page as an XML file, such asnam_metadata.xml. AD FS 2.0 uses this file to automate the setup of the Access Manager Claims Provider instance.

10.2.2 Configuring AD FS 2.0

Using Metadata to Add Claims Provider

You need to use the metadata import capabilities of AD FS 2.0 to create the Example.com claims provider. The metadata includes the public key that is used to validate security tokens signed by Access Manager.

Using Metadata to Add a Relying Party

  1. In AD FS 2.0, in the console tree, right-click the Claims Provider Trusts folder, then click Add Claims Provider Trust to start the Add Claims Provider Trust Wizard.

  2. Click Start.

  3. On the Select Data Source page, select Import data about the claims provider from a file.

  4. In the Federation metadata file location field, click Browse.

  5. Navigate to the location where you saved nam_metadata.xml, click Open, then click Next.

  6. On the Specify Display Name page, type NAM Example.

  7. Click Next > Next > Close.

Editing Claim Rules for the Claims Provider Trust

The following claim rule describes how the data from Access Manager is used in the security token that is sent to the WIF sample application or SharePoint 2010.

  1. In AD FS 2.0, click Relying Party Trusts, right click WIF Sample App, and then click Edit Claim Rules.

    or

    In the AD FS 2.0 center pane, under Claims Provider Trusts, right-click NAM Example, then click Edit Claim Rules.

  2. On the Acceptance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  4. Click Next.

  5. On the Configure Claim Rule page, use the following values:

    Name

    Value

    Claim rule name

    Name ID Rule

    Incoming claim type

    Name ID

    Incoming name ID format

    Unspecified

  6. Select the Pass through all claim values option and click Finish.

  7. Click Add Rule.

  8. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  9. Click Next.

  10. On the Configure Claim Rule page, under Claim rule name, use the following values:

    Name

    Value

    Claim rule name

    Name Rule

    Incoming claim type

    Name

  11. Leave the Pass through all claim values option selected and click Finish.

  12. To acknowledge the security warning, click Yes.

  13. Click OK.

  14. Click Add Rule.

  15. On the Select Rule Template page, select the Pass Through or Filter an Incoming Claim option.

  16. Click Next.

  17. On the Configure Claim Rule page, in the Claim rule name field, use the following values:

    Name

    Value

    Claim rule name

    Email Rule

    Incoming claim type

    E-Mail Address

  18. Leave the Pass through all claim values option selected and click Finish.

  19. To acknowledge the security warning, click Yes.

  20. Click OK.

Editing Claim Rules for the WIF Sample Application

At this point, incoming claims have been received at AD FS 2.0, but rules that describe what to send to the WIF sample application have not yet been created. You need to edit the existing claim rules for the sample application to take into account the new Access Manager external claims provider.

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click WIF Sample App, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass Name Rule

    Incoming claim type

    Name

  6. Leave the Pass through all claim values option selected, then click Finish.

  7. On the Issuance Transform Rules tab, click Add Rule.

  8. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim.

  9. Click Next.

  10. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Unspecified

  11. Leave the Pass through all claim values option selected, then click Finish.

  12. Click OK.

NOTE:If you changed the rules while federating AD FS 2.0 with the WIF sample application, ensure that you add the Permit All Users issuance rules back to the WIF sample application. See Step 6: – Change Rules in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guidehttp://technet.microsoft.com/en-us/library/adfs2-federation-wif-application-step-by-step-guide%28WS.10%29.aspx.

Or, as an alternative, add a new Permit or Deny Users Based on an Incoming Claim rule allowing incoming Name ID = john@example.com to access the application.

Editing Claim Rules for the SharePoint 2010 Application

At this point, incoming claims have been received at AD FS 2.0, but the rules that describe what to be sent to the SharePoint 2010 application have not yet been created. You need to edit the existing claim rules for the SharePoint 2010 application, which is added as relying party to ADFS 2.0, to configure the new Access Manager external claims provider.

Editing the Claim Rules for the SharePoint 2010 Application

  1. In AD FS 2.0, click Relying Party Trusts.

  2. Right-click SP2010, then click Edit Claim Rules.

  3. On the Issuance Transform Rules tab, click Add Rule.

  4. On the Select Rule Template page, click Pass Through or Filter an Incoming Claim > Next.

  5. On the Configure Claim Rule page, enter the following values:

    Name

    Value

    Claim rule name

    Pass eMail Rule

    Incoming claim type

    Email Address

  6. Leave the Pass through all claim values option selected and click Finish.

Changing the AD FS 2.0 Signature Algorithm

By default, Access Manager uses the Secure Hash Algorithm 1 (SHA-1) for signing operations. By default, AD FS 2.0 expects partners to use SHA-256. Complete the following steps to set AD FS 2.0 to expect SHA-1 for interoperability with Access Manager.

NOTE:The same procedure is recommended for AD FS 2.0 relying party trusts that use Access Manager. If the Access Manager SP signs authnRequests, artifact resolution requests, or logout requests, AD FS 2.0 errors occur unless this signature algorithm setting is changed.

  1. In AD FS 2.0, click Claims Provider Trusts.

  2. Right-click NAM Example > Properties.

  3. On the Advanced tab, select SHA-1 in the Secure Hash Algorithm list.

  4. Click OK.

Using Certificates and Certificate Revocation Lists

For security reasons, production federation deployments require the use of digitally signed security tokens, and optionally allows encryption of the security token contents. Self-signed private key certificates, which are generated from inside the AD FS 2.0 and Access Manager products, are used for signing security tokens.As an alternative, organizations can use a private key certificate that is issued by a certificate authority (CA) for signing and encryption. The primary benefit of using CA-issued certificates is the ability to check for possible certificate revocation against the certificate revocation list (CRL) from the issuing CA. Also, to avoid the untrusted certificate messages in browsers, the trusted root certificate of the CA must also be imported into your browsers. Many well-known CA's trusted roots are included with common browsers. Using one of these existing CAs to mint your certificates also prevents the untrusted certificate messages.

In AD FS 2.0 and in Access Manager, CRL checking is enabled by default for all partner connections, if the certificate being used by the partner includes a CRL Distribution Point (CDP) extension. This has implications in federation deployments between Access Manager and AD FS 2.0:

  • If a signing/encryption certificate provided by one side of a federation includes a CDP extension, that location must be accessible by the other side's federation server. Otherwise, CRL checking fails, resulting in a failed access attempt. The CDP extensions are added by default to certificates that are issued by Active Directory Certificate Services (AD CS) in Windows Server 2008 R2.

  • If the signing/encryption certificate does not include a CDP extension, no CRL checking is performed by AD FS 2.0 or Access Manager.

Disabling CRL Checking in the Linux Identity Server

  1. In Access Manager 3.1 SP4 or 3.1 SP5, modify the /opt/novell/nam/idp/conf/tomcat7.conf file and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

    or

    In Access Manager 3.2.x or 4.0, modify /opt/novell/nam/idp/conf/tomcat7.conf and add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

  2. To apply the changes, restart the Identity Server by running the /etc/init.d/novell-idp restart command.

Disabling CRL Checking in AD FS 2.0

  1. Click Start > Administrative Tools > Windows PowerShell Modules.

  2. Enter the following command at the PowerShell command prompt:

    set-ADFSClaimsProviderTrust -TargetName "NAM Example"

    -SigningCertificateRevocationCheck None

NOTE:You can make many configuration changes to AD FS 2.0 by using the Windows PowerShell command line and scripting environment. For more information, see the AD FS 2.0 Windows PowerShell Administration section of the AD FS 2.0 Operations Guide http://go.microsoft.com/fwlink/?LinkId=194005 and the AD FS 2.0 Cmdlets Reference http://go.microsoft.com/fwlink/?LinkId=177389.

10.2.3 Example Scenario: Access Manager as the Claims Provider and AD FS 2.0 as the Relying Party

Accessing the WIF Sample Application

In this scenario, John from Example.com accesses the Contoso WIF sample application.

NOTE:Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear the cookies, click Tools > Internet Options > Delete under Browsing History, and then select cookies for deletion.

  1. On the AD FS 2.0 computer, open a browser window, then navigate to https://fsweb.contoso.com/ClaimsAwareWebAppWithManagedSTS/default.aspx.

    The first page prompts you to select your organization from a list.

  2. Select NAM Example, then click Continue to sign in.

    When only one Identity Provider is available, AD FS 2.0 forwards the request to that Identity Provider by default.

  3. The NAM login page appears. Type the user name john, type the password test, then click Login.

Accessing the SharePoint 2010 Application

The user's email ID is used as the mapped attribute to access the SharePoint 2010 application. Assume that a user is created in the NetIQ Identity Server. The email ID configured for this user is namuser1@namidp.com.

NOTE:Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear the cookies, click Tools > Internet Options > Delete under Browsing History, then select cookies for deletion.

  1. Ensure that an email ID has been configured for the user in the Access Manager user store.

    For this example, use namuser1@namidp.com.

  2. Access the SharePoint 2010 application.

    The user is redirected to AD FS 2.0.

  3. Select NetIQ Identity Server.

    The user is redirected to the NAM IDP nidp page for authentication.

  4. Provide namuser1 as the username and password.

    After authentication, the user is redirected to the SharePoint application.