10.1 Using the Identity Server as an Identity Provider for ADFS

The Identity Server can provide authentication for resources protected by an Active Directory Federation Services (ADFS) server. This allows the Identity Server to provide single sign-on to Access Manager resources and ADFS resources, such as a SharePoint server. Figure 10-1 illustrates this configuration.

Figure 10-1 Accessing SharePoint Resources with an Identity Server

In this scenario, the following exchanges occur:

  1. The user requests access to a SharePoint server protected by the ADFS server.

  2. The resource sends an authentication request to the ADFS server.

  3. The ADFS server, which has been configured to use the Identity Server as an identity provider, gives the user the option of logging in to the Identity Server.

  4. The user logs in to the Identity Server and is provided a token that is sent to the ADFS server and satisfies the request of the resource.

  5. The user is allowed to access the resource.

The following section describe how to configure your servers for this scenario:

10.1.1 Configuring the Identity Server

Prerequisites

Creating a New Authentication Contract

The Microsoft ADFS server rejects the contract URI names of the default Access Manager contracts, which have a URI format of secure/name/password/uri. The ADFS server expects the URI to look like a URL.

We suggest that you use the following format for the URI of all contracts that you want to use with the ADFS server:

<baseurl>/name/password/uri

If the DNS name of your Identity Server is idp-50.amlab.net, the URI would have the following format:

https://idp-50.amlab.net:8443/nidp/name/password/uri

This URL doesn't resolve to anything because the Identity Server interprets it as a contract URI and not a URL.

To create a new authentication contract:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Local > Contracts.

  2. Click New, then fill in the following fields:

    Display name: Specify a name, for example WS-Fed Contract.

    URI: Specify a URI, for example https://idp-50.amlab.net:8443/nidp/name/password/uri.

    Satisfiable by External Provider: Enable this option. The ADFS server needs to satisfy this contract.

  3. Move Name/Password – Form to the Methods list.

  4. Click Next, then fill in the following fields:

    ID: Leave this field blank. You only need to supply a value when you want a reference that you can use externally.

    Text: Specify a description that is available to the user when the user mouses over the card.

    Image: Select an image, such as Form Auth Username Password. This is the default image for the Name/Password - Form contract.

    Show Card: Enable this option so that the card can be presented to the user as a login option.

  5. Click Finish.

  6. Continue with Setting the WS-Fed Contract to Be the Default Contract.

Setting the WS-Fed Contract to Be the Default Contract

It is not possible to specify the contract to request from the ADFS service provider to the Identity Server. You must either set the contract for WS-Fed to be the default, or have your users remember to click that contract every time.

  1. On the Local page of the Identity Server, click Defaults.

  2. For the Authentication Contract option, select the WS-Fed Contract.

  3. Click Apply.

  4. Continue with Enabling the STS and WS Federation Protocols.

Enabling the STS and WS Federation Protocols

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. In order to use the WS Federation protocol, you must enable it on the Identity Server. Because the WS Federation Protocol uses the STS (Secure Token Service) protocol, STS must also be enabled.

  1. Click the General tab.

  2. In the Enabled Protocols section, select the STS and WS Federation protocols.

  3. Click OK.

  4. Update the Identity Server.

  5. Continue with Creating an Attribute Set for WS Federation.

Creating an Attribute Set for WS Federation

The CardSpace attribute set is not in the correct namespace for WS Federation. The WS Federation namespace is http://schemas.xmlsoap.org/claims. Also, CardSpace has a defined set of claims. With WS Federation, you need to decide which attributes you want to share during authentication. This scenario uses the LDAP mail attribute and the All Roles attribute.

  1. On the Identity Servers page, click Shared Settings.

  2. To create a new attribute set, click New, then fill in the following fields:

    Set Name: Specify a name that identifies the purpose of the set, for example, wsfed_attributes.

    Select set to use as template: Select None.

  3. Click Next.

  4. To add a mapping for the mail attribute:

    1. Click New.

    2. Fill in the following fields:

      Local attribute: Select LDAP Attribute:mail [LDAP Attribute Profile].

      Remote attribute: Specify emailAddress. This is the attribute that this scenario uses for user identification.

      Remote nanespace: Select the radio button by the text box, then specify the following namespace:

      http://schemas.xmlsoap.org/claims

    3. Click OK.

  5. To add a mapping for the All Roles attribute:

    1. Click New.

    2. Fill in the following fields:

      Local attribute: Select All Roles.

      Remote attribute: Specify group. This is the name of the attribute that is used to share roles.

      Remote nanespace: Select the radio button by the text box, then specify the following namespace:

      http://schemas.xmlsoap.org/claims

    3. Click OK.

  6. Click Finish.

  7. Continue with Enabling the Attribute Set.

Enabling the Attribute Set

Because the WS Federation protocol uses STS, you must enable the attribute set for STS in order to use it in an WS Federation relationship.

  1. On the Identity Servers page, click Servers > Edit > STS.

  2. Move the WS Federation attribute set to the Attribute set list.

  3. Select the WS Federation attribute set and use the up-arrow to make it first in the Attribute set list.

  4. Click OK, then update the Identity Server.

Creating a WS Federation Service Provider

In order to establish a trusted relationship with the ADFS server, you need to set up the Trey Research site as a service provider. The trusted relationship allows the service provider to trust the Identity Server for user authentication credentials.

Trey Research is the default name for the ADFS resource server. If you have used another name, substitute it when following these instructions. To create a service provider, you need to know the following about the ADFS resource server.

Table 10-1 ADFS Resource Server Information

What You Need to Know

Default Value and Description

Provider ID

Default Value: urn:federation:treyresearch

This is the value that the ADFS server provides to the Identity Server in the realm parameter of the query string. This value is specified in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Service URI.

Sign-on URL

Default Value: https://adfsresource.treyresearch.net/adfs/ls/

This is the value that the identity provider redirects the user to after login. Although it is listed as optional, and is optional between two Novell Identity Servers, the ADFS server doesn't send this value to the identity provider. It is required when setting up a trusted relationship between an ADFS server and a Novell Identity Server.

This URL is listed in the Properties of the Trust Policy page on the ADFS server. The parameter label is Federation Services endpoint URL.

Logout URL

Default Value: https://adfsresource.treyresearch.net/adfs/ls/

This parameter is optional. If it is specified, the user is logged out of the ADFS server and the Identity Server.

Signing Certificate

This is the certificate that the ADFS server uses for signing.

You need to export it from the ADFS server. It can be retrieved from the properties of the Trust Policy on the ADFS Server on the Verification Certificates tab.This certificate is a self-signed certificate that you generated when following the Active Directory step-by-step guide.

To create a service provider configuration:

  1. On the Identity Servers page, click Edit > WS Federation.

  2. Click New > Service Provider, then fill in the following fields:

    Name: Specify a name that identifies the service provider, such as TreyResearch.

    Provider ID: Specify the provider ID of the ADFS server. The default value is urn:federation:treyresearch.

    Sign-on URL: Specify the URL that the user is redirected to after login. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    Logout URL: (Optional) Specify the URL that the user can use for logging out. The default value is https://adfsresource.treyresearch.net/adfs/ls.

    Service Provider: Specify the path to the signing certificate of the ADFS server.

  3. Click Next, confirm the certificate, then click Finish.

  4. Continue with Configuring the Name Identifier Format.

Configuring the Name Identifier Format

The Unspecified Name Identifier format is the default for a newly created WS Federation service provider, but this name identifier format doesn't work with the ADFS federation server. Additionally, some Group Claims (Adatum ClaimApp Claim and Adatum TokenApp Claim) must be satisfied in order to gain access to the SharePoint server.

  1. On the WS Federation page, click the name of the TreyResearch service provider.

  2. Click Attributes, then fill in the following fields:

    Attribute set: Select the WS Federation attribute set you created.

    Send with authentication: Move the All Roles attribute to the Send with authentication list.

  3. Click Apply, then click Authentication Response.

  4. Select E-mail for the Name Identifier Format.

  5. Select LDAP Attribute:mail [LDAP Attribute Profile] as the value for the e-mail identifier.

  6. Click OK twice, then update the Identity Server.

  7. Continue with Setting Up Roles for ClaimApp and TokenApp Claims.

Setting Up Roles for ClaimApp and TokenApp Claims

When users access resources on the ADFS server, they need to have two roles assigned: a ClaimApp role and a TokenApp role. The following steps explain how to create these two roles so that they are assigned to all users that log in to the Identity Server.

  1. On the Identity Servers page, click Edit > Roles > Manage Policies.

  2. Click New, specify a name for the policy, select Identity Server: Roles, then click OK.

  3. On the Rule 1 page, leave Condition Group 1 blank.

    With no conditions to match, this rule matches all authenticated users.

  4. In the Actions section, click New > Activate Role.

  5. In the text box, specify ClaimApp.

  6. In the Actions section, click New > Activate Role.

  7. In the text box, specify TokenApp.

  8. Click OK twice, then click Apply Changes.

  9. Click Close.

  10. On the Roles page, select the role policy you just created, then click Enable.

  11. Click OK, then update the Identity Server.

  12. Continue with Importing the ADFS Signing Certificate into the NIDP-Truststore.

Importing the ADFS Signing Certificate into the NIDP-Truststore

The Novell Identity Provider (NIDP) must have the trusted root of the ADFS signing certificate (or the certificate itself) listed in its Trust Store, as well as specified in the relationship. This is because most ADFS signing certificates are part of a certificate chain, and the certificate that goes into the metadata is not the same as the trusted root of that certificate. However, because the Active Directory step-by-step guide uses self-signed certificates for signing, it is the same certificate in both the Trust Store and in the relationship.

To import the ADFS signing certificate’s trusted root (or the certificate itself) into the NIDP-Truststore:

  1. On the Identity Servers page, click Edit > Security > NIDP Trust Store.

  2. Click Add.

  3. Next to the Trusted Root(s) field, click the Select Trusted Root(s) icon.

    This adds the trusted root of the ADFS signing certificate to the Trust Store.

  4. On the Select Trusted Roots page, select the trusted root or certificate that you want to import, then click Add Trusted Roots to Trust Stores.

    If there is no trusted root or certificate in the list, click Import. This enables you to import a trusted root or certificate.

  5. Next to the Trust store(s) field, click the Select Keystore icon.

  6. Select the trust stores where you want to add the trusted root or certificate, then click OK twice.

  7. Update the Identity Server so that the changes can take effect.

This finishes the configuration that must be done on the Identity Server for the Identity Server to trust the ADFS server. The ADFS server must be configured to trust the Identity Server. Continue with Section 10.1.2, Configuring the ADFS Server.

10.1.2 Configuring the ADFS Server

The following tasks must be completed on the Trey Research server (adfsresouce.treyresearch.net) to establish trust with the Novell Identity Server.

Enabling E-mail as a Claim Type

There are three types of claims for identity that can be enabled on an ADFS server. They are Common Name, E-mail, 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 e-mail name that looks the same, it is not. This scenario selects to use E-mail instead of Common Name because E-mail is a more common configuration.

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

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

  3. Verify that E-mail is in this list. If it isn’t, move it to the list.

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

  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 the identity provider and the service provider must be configured to trust the other provider. This task sets up the trust between the ADFS server and the Identity Server.

  1. In the Active Directory Federation Services console, navigate to the Account Partners by clicking Federation Services >Trust Policy > Partner Organizations.

  2. Right-click Partner Organizations, then select New > Account Partner.

  3. Supply the following information in the wizard:

    • You do not have an account partner policy file.

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

    • For the Federation Services URI, specify the following:

      https://<DNS_Name>:8443/nidp/wsfed/

      Replace <DNS_Name> with the DNS name of the 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 the following:

      https://<DNS_Name>:8443/nidp/wsfed/ep

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

      This URL 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.

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

    • Select the E-mail claim.

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

      You need to have the e-mail end in a suffix that the ADFS server is expecting, such as @novell.com, which grants access to any user with that e-mail 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 these roles to be used by the resources. You set them up to be sent in the All Roles attribute from the 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 the 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, the ADFS has a mandatory requirement to do CRL checking on any certificate that they receive. For instructions on how to disable this checking, see “Turn CRL checking on or off”.

Use the following tips as 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 your Identity Server is idp-50.amlab.net, replace it with https://idp-50.amlab.ne:8443/nidp/wsfed/.

    Your command should look similar to the following:

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

10.1.3 Logging In

  1. In a browser on your client machine, enter the URL of the SharePoint server. For example:

    https://adfsweb.treyresearch.net/default.aspx

  2. Select the IDP from the drop-down list of home realm, then submit the request.

    If you are not prompted for the realm, clear all cookies in the browser and try again.

  3. Log in with a user at the Novell Identity Provider

  4. Verify that you can access the SharePoint server.If you only see a page that says Server Error in '/adfs' Application, see Turning On Logging on the ADFS server and follow the instructions in Common Errors.

10.1.4 Troubleshooting

Turning On Logging on the ADFS server

If you see the message Server Error in '/adfs' Application displayed in the client's browser, the best place to look for the cause is in the ADFS log file.

To turn on this log file:

  1. In the Active Directory Federation Services console, right-click Federation Service, then click Properties.

  2. Click the Troubleshooting tab, then enable everything on the page.

  3. Click OK, then look for the file that is created in the path listed in the Log files directory.

  4. Look in that file for reasons that the federation is failing.

    For an explanation of some of the common errors, see Common Errors.

Common Errors

[ERROR] SamlViolatesSaml:

Error parsing AuthenticationMethod: Invalid URI: The format of the URI could not be determined.

Cause: This is because the contract has the wrong format for its URI. The URI must start with urn: or http://. Change the contract and try again.

[ERROR] Saml contains an unknown NameIdentifierFormat:

Issuer=https://idp-51.amlab.net:8443/nidp/wsfed/; Format=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Cause: The name identifier format is set to unspecified, and it needs to be set to E-mail.

[ERROR] Saml contains an unknown Claim name/namespace:

Issuer=https://idp-51.amlab.net:8443/nidp/wsfed/; Namespace=urn:oasis:names:tc:SAML:1.0:assertion; Name=emailaddress

Cause: The emailAddress attribute is not in the correct namespace for WSFed.

CRL Errors

  • 2008-08-01T19:56:55 [WARNING] VerifyCertChain: Cert chain did not verify - error code was 0x80092012

  • 2008-08-01T19:56:55 [ERROR] KeyInfo processing failed because the trusted certificate does not have a a valid certificate chain. Thumbprint = 09667EB26101A98F44034A3EBAAF9A3A09A0F327

  • 2008-08-01T19:56:55 [WARNING] Failing signature verification because the KeyInfo section failed to produce a key.

  • 2008-08-01T19:56:55 [WARNING] SAML token signature was not valid: AssertionID = idZ0KQH0kfjVK8kmKfv6YaVPglRNo

Cause: The CRL check isn't turned off. See Disabling CRL Checking.

[ERROR] EmailClaim.set_Email:

Email 'mPmNXOA8Rv+j16L1iNKn/4HVpfeJ3av1L9c0GQ==' has invalid format

Cause: The drop-down list next to E-mail in the identifier format was not changed from <Not Specified> to a value with a valid e-mail address in it.