Configuring the ADFS Server

You must complete the following tasks on the Trey Research server (adfsresouce.treyresearch.net) to establish trust with Access Manager Identity Server:

Enabling Email as a Claim Type

You can enable three types of claims for identity that can be enabled on an ADFS server. The claims include Common Name, Email, and User Principal Name. The ADFS step-by-step guide specifies that you do everything with a User Principal Name, which is an Active Directory convention. Although it could be given an email name that looks the same, it is not. This scenario selects to use Email instead of Common Name because Email is a more common configuration.

  1. From the Administrative Tools, open the Active Directory Federation Services tool.

  2. Navigate to Organizational Claims by clicking Federation Service > Trust Policy > My Organization.

  3. Verify that Email is in this list. If it is not, move it to the list.

  4. Navigate to your Token-based Application and enable email by right-clicking the application, editing the properties, and selecting Enabled.

  5. Navigate to your Claims-aware Application and repeat the process.

  6. Continue with Creating an Account Partners Configuration.

Creating an Account Partners Configuration

WS Federation requires a two-way trust relationship. Both identity provider and service provider must be configured to trust each other.

  1. In the Active Directory Federation Services console, click Federation Services >Trust Policy > Partner Organizations.

  2. Right-click Partner Organizations and select New > Account Partner.

  3. Specify the following information in the wizard:

    • You do not have an account partner policy file.

    • For the display name, specify the DNS name of Identity Server.

    • For the Federation Services URI, specify https://<DNS_Name>:8443/nidp/wsfed/.

      Replace <DNS_Name> with the DNS name of Identity Server. This URI is the base URL of your Identity Server with the addition of /wsfed/ on the end.

    • For the Federation Services endpoint URL, specify https://<DNS_Name>:8443/nidp/wsfed/ep.

      Replace <DNS_Name> with the DNS name of Identity Server.

      This is the base URL of your Identify Server with the addition of /wsfed/ep at the end.

    • For the verification certificate, import the trusted root of the signing certificate on your Identity Server.

      If you have not changed it, you need the Organizational CA certificate from your Administration Console. This is the trusted root for the test-signing certificate.

    • Select Federated Web SSO.

      Identity Server is outside of any forest, so do not select Forest Trust.

    • Select the Email claim.

    • Add the suffix that you will be using for your e-mail address.

      You need to have the email end in a suffix that the ADFS server is expecting, such as @novell.com, which grants access to any user with that email suffix.

  4. Enable this account partner.

  5. Finish the wizard.

  6. Continue with Enabling ClaimApp and TokenApp Claims.

Enabling ClaimApp and TokenApp Claims

The Active Directory step-by-step guide sets up the roles to be used by the resources. You set them up to be sent in the All Roles attribute from Identity Server. You must map these roles into the Adatum ClaimApp Claim and the Adatum TokenApp Claim.

  1. In the Active Directory Federation Services console, click the account partner that you created for Identity Server (see Creating an Account Partners Configuration).

  2. Right-click the account partner, then create a new Incoming Group Claim Mapping with the following values:

    Incoming group claim name: Specify ClaimApp.

    Organization group claim: Specify Adatum ClaimApp Claim.

  3. Right-click the account partner, and create another Incoming Group Claim Mapping with the following values:

    Incoming group claim name: Specify TokenApp.

    Organization group claim: Specify Adatum TokenApp Claim.

  4. Continue with Disabling CRL Checking.

Disabling CRL Checking

If you are using the Access Manager certificate authority as your trusted root for the signing certificate (test-signing certificate), there is no CRL information in that certificate. However, ADFS has a mandatory requirement to perform CRL check on any certificate that they receive. For more information, see “Turn CRL checking on or off”.

Use the following information when you follow these instructions:

  • Create a file from the script contained at that link called TpCrlChk.vbs.

  • Exit the Active Directory Federation Services console.

    If you do not exit the console, the console overwrites the changes made by the script file and CRL checking is not turned off.

  • Run the command with the following syntax:

    Cscript TpCrlChk.vbs <location of ADFS>\TrustPolicy.xml "<service URI>" None

    Replace <location of ADFS> with the location of the ADFS TrustPolicy.xml file. The default location is C:\ADFS\TrustPolicy.xml.

    Replace <service URI> with the URI you specified in Step 3. If the DNS name of Identity Server is idp-50.amlab.net, replace it with https://idp-50.amlab.ne:8443/nidp/wsfed/.

    Your command must look similar to the following:

    Cscript TpCrlChk.vbs C:\ADFS\TrustPolicy.xml "https://idp-50.amlab.net:8443/nidp/wsfed/" None