The Active Directory Federation Services server can be configured to provide authentication for a resource protected by Access Manager.
Figure 10-2 Using an ADFS Server for Access Manager Authentication
In this scenario, the following exchanges occur:
The user requests access to a resource protected by an Access Gateway.
The resource sends an authentication request to the Novell Identity Server.
The Identity Server is configured to trust an Active Directory Federation Services server and gives the user the option of logging in at the Active Directory Federation Services server.
The user logs into the Active Directory Federation Services server and is provided a token
The token is sent to the Identity Server.
The token satisfies the authentication requirements of the resource, so the user is allowed to access the resource.
The following sections describe how to configure this scenario.
You have set up the Active Directory Federation Services, Active Directory, and SharePoint servers and the client as described in the ADFS guide from Microsoft. See the “Step-by-Step Guide for Active Directory Federation Services”.
You have set up the Novell Access Manager 3.1 system with a site configuration that is using SSL in the Identity Server's base URL. See Enabling SSL Communication
in the Novell Access Manager 3.1 SP2 Setup Guide.
Enable the Liberty Personal Profile.
In the Administration Console, click
> > > . Select the , then click > . Update the Identity Server.Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. In order to use the WS Federation protocol, it must be enabled on the Identity Server. Because the WS Federation Protocol uses the STS (Secure Token Service) protocol, STS must also be enabled.
In the Administration Console, click
> > .In the
section of the General Configuration page, enable the STS and WS Federation protocols.Click
.Update the Identity Server.
Continue with Creating a WS Federation Identity Provider.
In order to have a trust relationship, you need to set up the Adatum site (adfsaccount.adatum.com) as an identity provider for the Identity Server.
Adatum is the default name for the identity provider. If you have used another name, substitute it when following these instructions. To create an identity provider, you need to know the following information about the Adatum site:
Table 10-2 Adatum Values
To create an identity provider:
In the Administration Console, click
> > > .On the WS Federation page, click
, select , then fill in the following fields:Name: Specify a name that identifies the identity provider, such as Adatum.
Provider ID: Specify the federation service URI of the identity provider, for example urn:federation:adatum.
Sign-on URL: Specify the URL for logging in, such as https://adfsaccount.adatum.com/adfs/ls/.
Logout URL: Specify the URL for logging out, such as https://adfsresource.treyresearch.net/adfs/ls/
Identity Provider: Specify the path to the signing certificate of the ADFS server.
Confirm the certificate, then click
.For the authentication card, specify the following values:
ID: Leave this field blank.
Text: Specify a description that is available to the user when the user mouses over the card.
Image: Select an image, such as
, or any other image.Show Card: Enable this option so that the card can be presented to the user as a login option.
Click
.Continue with Modifying the User Identification Specification.
The default settings for user identification are set to do nothing. The user can authenticated but the user is not identified as a local user on the system. This is not the scenario we are configuring. We want the user to be identified on the local system. Additionally, we want to specify which contract on the Access Gateway is satisfied with this identification. If a contract is not specified, the Access Gateway resources must be configured to use the
option, which is not a typical configuration.On the WS Federation page, click the name of the Adatum identity provider configuration.
Click
.For
, select .Select
.For the
, select .Click
twice.Update the Identity Provider.
Continue with Importing the ADFS Signing Certificate into the NIDP-Truststore.
The Identity Server 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 have a 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:
On the Identity Servers page, click
> > .Click
.Next to the
field, click the icon.This adds the trusted root of the ADFS signing certificate to the Trust Store.
On the Select Trusted Roots page, select the trusted root or certificate that you want to import, then click
.If there is no trusted root or certificate in the list, click
. This enables you to import a trusted root or certificate.Next to the
field, click the icon.Select the trust stores where you want to add the trusted root or certificate, then click
twice.Update the Identity Server so that changes can take effect.
This ends the basic configuration that must be done to for the Identity Server to trust the ADFS server as an identity provider. However, the ADFS server needs to be configured to act as an identity server and to trust the Identity Server. Continue with Section 10.2.2, Configuring the ADFS Server to Be an Identity Provider.
The following tasks describe the minimum configuration required for the ADFS server to act as an identity provider for the Access Manager Identity Server.
For additional configuration options, see Section 10.2.4, Additional WS Federation Configuration Options.
You can enable three types of claims for identity on an ADFS Federation 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 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.
In the Administrative Tools, open the
tool.Navigate to the
by clicking > > .Make sure that E-mail is in this list.
Navigate to Active Directory by clicking
> > .Enable the
:Right-click this claim, then select
.Click the
box.Add the LDAP mail attribute by clicking
> and selecting .This is the LDAP attribute in Active Directory where the user’s e-mail address is stored.
Click
.Verify that the user you are going to use for authentication has an E-mail address in the mail attribute.
Continue with Creating a Resource Partner.
The WS Federation protocol requires a two-way trust. The identity provider must be configured to trust the service provider, and the service provider must be configured to trust the identity provider. You have already set up the service provider to trust the identity provider (see Creating a WS Federation Identity Provider). This section sets up the trust so that the identity provider (the ADFS server) trusts the service provider (the Identity Server).
In the Active Directory Federation Services console, access the Resource Partners page by clicking
> > .Right-click the
, then click > .Supply the following information in the wizard:
You do not have a resource partner policy file to import.
For the display name, specify the DNS name of the Identity Server.
For the
, enter the following:
https://<DNS_Name>:8443/nidp/wsfed/
Replace <DNS_Name> with the name of your Identity Server.
This is the base URL of your Identity Server with the addition of /wsfed/ at the end.
For the Federation Services endpoint URL, specify the following:
https://<DNS_Name>:8443/nidp/wsfed/spassertion_consumer
Replace <DNS_Name> with the name of your Identity Server.
This is the base URL of your Identity Server with the addition of /wsfed/spassertion_consumer at the end.
Select
.The Identity Server is outside of any forest, so do not select
.Select the E-mail claim.
Select the
option.Enable this resource partner.
Finish the wizard.
To test the configuration, continue with Section 10.2.3, Logging In.
In a client browser, enter the base URL of your Identity Server.
From the list of cards, select the Adatum contract.
(Conditional) If you are not joined to the Adatum domain, enter a username and password in the browser pop-up. Use a name and a password that are valid in the Adatum domain.
If you are using the client that is joined to the Adatum domain, the card uses a Kerberos ticket to authenticate to the ADFS identity provider (resource partner).
When you are directed back to the Identity Server for Federation User Identification, log in to the Identity Server with a username and password that is valid for the Identity Server (the service provider).
Verify that you are authenticated.
Close the browser.
Log in again.
This time you are granted access without entering credentials at the service provider.
You can enable the sharing of attribute information from the Identity Server to the ADFS server. This involves creating an attribute set and enabling the sending of the attributes at authentication. See Section 10.4.2, Configuring the Attributes Obtained at Authentication.
For other options that can be modified after you have created the trusted identity server configuration, see Section 10.4, Modifying a WS Federation Identity Provider.