Configuring Access Manager as a Claims or Identity Provider and AD FS 2.0 as a 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.

Configuring Access Manager

NOTE:To deploy this identity federation, 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 ADFS Metadata to Add a New 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 AD FS metadata file 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.

Adding a New Service Provider Connection

  1. Click Devices > Identity Server > Edit > SAML 2.0 > New > Add Service Provider.

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

  3. Select Metadata Text from Source.

  4. In Text, specify AD FS metadata that you copied in Step 5.

  5. Click Next > Finish.

  6. Update Identity Server.

Adding an AD FS Server Trusted Certificate

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

  2. Click Security > Certificates > Trusted Roots > Import.

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

  4. Click OK.

  5. Click Uploaded AD FS CA.

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

  7. Update Identity Server.

Creating an Attribute Set in Access Manager

  1. Click Devices > Identity Servers > Shared Settings > Attribute Sets > 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 Local Attribute.

  6. Specify emailaddress in Remote attribute.

  7. Select http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ from Remote namespace.

  8. Click OK.

  9. Click New.

  10. Select All Roles from Local Attribute.

  11. Specify roles in Remote Attribute.

  12. Select http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ from Remote namespace.

  13. Click OK.

  14. Update Identity Server.

Configuring the Service Provider in Access Manager

  1. 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 Attribute Set.

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

  8. Click OK.

  9. Update 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 XML, such asnam_metadata.xml. AD FS 2.0 uses this XML to automate the setup of the Access Manager Claims Provider instance.

Configuring AD FS 2.0

Using Metadata to Add Claims Provider

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 click Edit Claim Rules.

    or

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

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

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

  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 Pass through all claim values and click Finish.

  7. Click Add Rule.

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

  9. On the Configure Claim Rule page, under Claim rule name, specify the following values:

    Name

    Value

    Claim rule name

    Name Rule

    Incoming claim type

    Name

  10. Keep Pass through all claim values selected and click Finish.

  11. To acknowledge the security warning, click Yes.

  12. Click OK.

  13. Click Add Rule.

  14. On the Select Rule Template page, select Pass Through or Filter an Incoming Claim, and click Next.

  15. On the Configure Claim Rule page, specify the following values under Claim rule name:

    Name

    Value

    Claim rule name

    Email Rule

    Incoming claim type

    E-Mail Address

  16. Keep Pass through all claim values selected and click Finish.

  17. To acknowledge the security warning, click Yes.

  18. 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, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name Rule

    Incoming claim type

    Name

  6. Keep Pass through all claim values 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 > Next.

  9. On the Configure Claim Rule page, specify the following values:

    Name

    Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Unspecified

  10. Keep Pass through all claim values selected, then click Finish.

  11. 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 Guide.

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, specify 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.

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 2012.

  • 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 Identity Server

  1. Modify the tomcat.conf file.

    For information about how to modify a file, see Modifying Configurations.

  2. Add JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

Disabling CRL Checking in AD FS 2.0

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

  2. Run the following command in 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 AD FS 2.0 Windows PowerShell Administration of the AD FS 2.0 Operations Guide and AD FS 2.0 Cmdlets Reference.

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 cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear 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 Access Manager Identity Server. The email ID configured for this user is namuser1@namidp.com.

NOTE:Clear all cookies in the Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). 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 Access Manager Identity Server nidp page for authentication.

  4. Provide namuser1 as the username and password. After authentication, the user is redirected to the SharePoint application.