4.2.8 Configuring WS Federation

The first two topics in this section describe two different methods for setting up federation with a SharePoint server. The next sections describe how you can manage and modify WS Federation providers and configure Security Token Service (STS). STS is used to process authentication requests received at Identity Server for the WS Federation protocol.

You can obtain the WS-Federation metadata by using Samlv2Meta as described in the WS-Federation 1.1 and 1.2 specification. To obtain the metadata, use the following URL format:

<base-url>/nidp/wsfed/metadata?type=Samlv2Meta.

(Access Manager 4.5 Service Pack 4 and later) An EntityID attribute is added to the EntityDescriptor in Access Manager WS-Federation metadata. This attribute can be queried when using <base-url>/nidp/wsfed/metadata?type=Samlv2Meta endpoint.

Using Identity Server as an Identity Provider for ADFS

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

Figure 4-13 Accessing SharePoint Resources with Identity Server

In this scenario, the following events occur:

  1. A 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 Identity Server as an identity provider, gives the user the option of logging in to Identity Server.

  4. The user logs in to 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:

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

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 look similar to the following format:

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

This URL does not resolve to anything because Identity Server interprets it as a contract URI and not a URL.

To create a new authentication contract:

  1. Click Devices > Identity Servers > Edit > Local > Contracts.

  2. Click New, then specify the following details:

    Field

    Description

    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

    Select this option. The ADFS server needs to satisfy this contract.

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

  4. Click Next, then specify the following details:

    Field

    Description

    ID

    Leave this field blank. 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 hovers 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

    Select 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 as the Default Contract.

Setting the WS-Fed Contract as the Default Contract

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

  1. Click Devices > Identity Servers > Servers > Edit > Local > Defaults.

  2. In Authentication Contract, select the WS-Fed Contract.

  3. Click Apply.

  4. Continue with Enabling the WS Federation Protocol.

Enabling the WS Federation Protocol

By default, only SAML 1.1, Liberty, and SAML 2.0 are enabled. To use the WS Federation protocol, you must enable it on Identity Server.

  1. Click Devices > Identity Servers > Servers > Edit > General.

  2. In the Enabled Protocols section, select WS Federation.

  3. Click OK.

  4. Update Identity Server.

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

Creating an Attribute Set for WS Federation

The WS Federation namespace is http://schemas.xmlsoap.org/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. Click Devices > Identity Server > Shared Settings > Attribute Sets > New.

  2. Specify the following details:

    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, perform the following steps:

    1. Click New.

    2. Specify the following details:

      Field

      Description

      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 namespace

      Select the option, and then specify the following namespace

      http://schemas.xmlsoap.org/claims

    3. Click OK.

  5. To add a mapping for the All Roles attribute, perform the following steps:

    1. Click New.

    2. Specify the following details:

      Field

      Description

      Local attribute

      Select All Roles.

      Remote attribute

      Specify group.

      This is the name of the attribute that is used to share roles.

      Remote namespace

      Select the option, and 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

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

  1. Click Devices > Identity Servers > Servers > Edit > WS Federation > STS Attribute Sets.

  2. Move the WS Federation attribute set to the Attribute sets 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 Identity Server.

Creating a WS Federation Service Provider

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 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 details about the ADFS resource server:

Table 4-3 ADFS Resource Server Information

Option

Default Value

Description

Provider ID

urn:federation:treyresearch

This is the value that the ADFS server provides to 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

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

The identity provider redirects this value to the user after login. Although it is listed as optional, and is optional between two Access Manager Identity Servers, the ADFS server does not send this value to the identity provider. It is required when setting up a trusted relationship between an ADFS server and a Access Manager 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

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

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

Signing Certificate

NA

The ADFS server uses this certificate 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, perform the following steps:

  1. Click Devices > Identity Servers > Servers > Edit > WS Federation.

  2. Click New > Service Provider, then specify the following details:

    Field

    Description

    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, and 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 does not work with the ADFS federation server. Additionally, some Group Claims (Adatum ClaimApp Claim and Adatum TokenApp Claim) must be satisfied 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 specify the following details:

    Field

    Description

    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 > OK, then update 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 Identity Server.

  1. Click Devices > Identity Servers > Servers > 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. Specify ClaimApp.

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

  7. Specify TokenApp.

  8. Click OK > OK, 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 Identity Server.

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

Importing the ADFS Signing Certificate into the NIDP-Truststore

The Access Manager Identity Provider (NIDP) must have the trusted root of the ADFS signing certificate (or the certificate itself) listed in its trust store, and 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. 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, perform the following steps:

  1. Click Devices > Identity Servers > Servers > Edit > Security > NIDP Trust Store.

  2. Click Add.

  3. Next to Trusted Root(s), 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 Trust store(s), click the Select Keystore icon.

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

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

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

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 E-mail 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, 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 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 Identity Server.

    • For the Federation Services URI, specify the following:

      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 the following:

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

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

      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 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, the ADFS has a mandatory requirement to perform CRL checking on any certificate that they receive. For information about how to disable this checking, 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 your 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

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 as a user at the Access Manager Identity Provider

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

Troubleshooting

Enabling Logging on the ADFS Server

If you see the message Server Error in '/adfs' Application displayed in the client's browser, you can verify the ADFS log file to find the cause.

To enable logging, perform the following steps:

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

  2. Select Troubleshooting, then enable all options 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 the reasons of the issue.

    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.

Using the ADFS Server as an Identity Provider for an Access Manager Protected Resource

You can configure the ADFS server to provide authentication for a resource protected by Access Manager.

Figure 4-14 Using an ADFS Server for Access Manager Authentication

In this scenario, the following exchanges occur:

  1. The user requests access to a resource protected by Access Gateway.

  2. The resource sends an authentication request to Access Manager Identity Server.

  3. Identity Server is configured to trust an ADFS server and gives the user the option of logging in at the ADFS server.

  4. The user logs in to the ADFS server and is provided a token.

  5. The token is sent to Identity Server.

  6. The token satisfies the authentication requirements of the resource, and the user is allowed to access the resource.

The following sections describe how to configure this scenario:

Configuring Identity Server as a Service Provider

Prerequisites

  • You have set up ADFS, 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 Access Manager with a site configuration that is using SSL in Identity Server's base URL. See Section 19.0, Enabling SSL Communication.

  • Enable the Liberty Personal Profile.

    Click Identity Servers > Edit > Liberty > Web Service Provider. Select the Personal Profile, then click Enable > Apply. Update Identity Server.

Enabling the WS Federation Protocol

Access Manager ships with only SAML 1.1, Liberty, and SAML 2.0 enabled by default. To use the WS Federation protocol, it must be enabled on Identity Server.

  1. Click Devices > Identity Servers > Edit.

  2. In the Enabled Protocols section of the General Configuration page, select WS Federation.

  3. Click OK.

  4. Update Identity Server.

  5. Continue with Creating a WS Federation Identity Provider.

Creating a WS Federation Identity Provider

To have a trust relationship, you need to set up the Adatum site (adfsaccount.adatum.com) as an identity provider for 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 4-4 Adatum Values

Option

Default Value and Description

Provider ID

Default Value: urn:federation:adatum

The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI.

Sign-on URL

Default Value: https://adfsaccount.adatum.com/adfs/ls/

The service provider uses this value to redirect the user for login. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

Logout URL

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

The ADFS server makes no distinction between the login and logout URL. Access Manager has separate URLs for login and logout, but from an Access Manager Identity Server to an ADFS server, they are the same.

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 step-by-step guide.

To create an identity provider, perform the following steps:

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click New, select Identity Provider, and then specify the following details:

    Field

    Description

    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.

  3. Confirm the certificate, then click Next.

  4. For the authentication card, specify the following values:

    Field

    Description

    ID

    Leave this field blank.

    Text

    Specify a description that is available to the user when the user hovers the mouse over the card.

    Image

    Select an image, such as Customizable, or any other image.

    Show Card

    Select this option to display the card as a login option.

  5. Click Finish.

  6. Continue with Modifying the User Identification Specification.

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. However, in this scenario, the user must be identified on the local system. Additionally, You need to specify which contract on Access Gateway is satisfied with this identification. If a contract is not specified, Access Gateway resources must be configured to use the Any Contract option, which is not a typical configuration.

  1. On the WS Federation page, click the name of the Adatum identity provider configuration.

  2. Click User Identification.

  3. For Satisfies contract, select Name/Password – Form.

  4. Select Allow federation.

  5. For the User Identification Method, select Authenticate.

  6. Click OK > OK.

  7. Update Identity Server.

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

Importing the ADFS Signing Certificate into the NIDP-Truststore

Identity Server must have the trusted root of the ADFS signing certificate (or the certificate itself) listed in its trust store, and 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, as 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, perform the following steps:

  1. Click Devices > Identity Servers > Edit > Security > NIDP Trust Store.

  2. Click Add.

  3. Next to Trusted Root(s), 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 Trust store(s), 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 Identity Server.

Continue with Configuring the ADFS Server to Be an Identity Provider.

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 Access Manager Identity Server:

For additional configuration options, see Additional WS Federation Configuration Options.

Enabling a Claim Type for a Resource Partner

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.

  1. In 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. Ensure that E-mail is in this list.

  4. Navigate to Active Directory by clicking Federation Services > Trust Policy > Account Stores.

  5. Enable the E-mail Organizational Claim:

    1. Right-click this claim, then select Properties.

    2. Click the Enabled box.

    3. Add the LDAP mail attribute by clicking Settings > LDAP attribute and selecting mail.

      This is the LDAP attribute in Active Directory where the user’s e-mail address is stored.

    4. Click OK.

  6. Verify that the user you are going to use for authentication has an E-mail address in the mail attribute.

  7. Continue with Creating a Resource Partner.

Creating a Resource Partner

WS Federation requires the 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 (Identity Server).

  1. In the Active Directory Federation Services console, access the Resource Partners page by clicking Federation Services > Trust Policy > Partner Organizations.

  2. Right-click the Partner Organizations, then click New > Resource Partner.

  3. 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 Identity Server.

    • For the Federation Services URI, 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 Federated Web SSO.

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

    • Select the E-mail claim.

    • Select the Pass all E-mail suffixes through unchanged option.

  4. Enable this resource partner.

  5. Finish the wizard.

  6. To test the configuration, continue with Logging In.

Logging In

  1. In a client browser, enter the base URL of your Identity Server.

  2. From the list of cards, select the Adatum contract.

  3. (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).

  4. When you are directed back to Identity Server for Federation User Identification, log in to Identity Server with a username and password that is valid for Identity Server (the service provider).

  5. Verify that you are authenticated.

  6. Close the browser.

  7. Log in again.

    This time you are granted access without entering credentials at the service provider.

Additional WS Federation Configuration Options

You can enable the sharing of attribute information from Identity Server to the ADFS server. This involves creating an attribute set and enabling the sending of the attributes at authentication. See Configuring the Attributes Obtained at Authentication.

For other options that can be modified after you have created the trusted identity server configuration, see Modifying a WS Federation Identity Provider.

Managing WS Federation Providers

The WS Federation page allows you to create or edit trusted identity providers and trusted service providers. When you create an identity provider configuration, you are configuring Identity Server to be a WS Federation resource partner. When you create a service provider configuration, you are configuring Identity Server to be a WS Federation account partner.

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Select one of the following actions:

    New: Launches the Create Trusted Identity Provider Wizard or the Create Trusted Service Provider Wizard, depending on your selection. For more information, see one of the following:

    Delete: Allows you to delete the selected identity or service provider. This action deletes the definition.

    Enable: Enables the selected identity or service provider.

    Disable: Disables the selected identity or service provider. When the provider is disabled, the server does not load the definition. However, the definition is not deleted.

    Modify: Click the name of a provider. For configuration information, see Modifying a WS Federation Identity Provider or Modifying a WS Federation Service Provider.

  3. Click OK, then update Identity Server.

Creating an Identity Provider for WS Federation

To have a trust relationship, you need to set up the ADFS server as an identity provider for Identity Server.

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click New, select Identity Provider, then specify the following details:

    Field

    Description

    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.

  3. Confirm the certificate, then click Next.

  4. For the authentication card, specify the following values:

    Field

    Description

    ID

    Leave this field blank.

    Text

    Specify a description that is available to the user when the user hovers the mouse over the card.

    Image

    Select an image, such as Customizable, or any other image.

    Show Card

    Select this option to display the card as a login option.

  5. Click Finish.

For information about additional configuration steps required to use this identity provider, see Using the ADFS Server as an Identity Provider for an Access Manager Protected Resource.

If you want to use Access Manager as a WS Federation identity provider and consumer, perform the following steps:

NOTE:Use this setup only in the test environment and not in the production environment.

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click New > Identity Provider, then specify the following details:

    Field

    Description

    Name

    Specify a name that identifies the identity provider.

    Provider ID

    https://240onbox.nam.example.com:8443/nidp/wsfed/

    Sign-on URL

    https://240onbox.nam.example.com:8443/nidp/wsfed/ep.

    Logout URL

    https://240onbox.nam.example.com:8443/nidp/wsfed/loreply

  3. Upload the test-signing certificate of the trusted identity provider.

    NOTE:You can get the test-signing certificate from Dashboard > Certificates > test-signing > Export Public Certificate > DER File.

  4. Click Next.

  5. For the authentication card, specify the following values:

    Field

    Description

    ID

    Specify an alphanumeric value. This value is persistent.

    If you do not assign a value, Identity Server creates an internal value that keeps changing whenever you restart the Identity Server.

    Text

    Specify a description to help a user understand the authentication method of the card.

    This description is displayed when the user hovers over the authentication card.

    Image

    Select an image.

    Show Card

    Select this option to display the card as a login option.

  6. Click Finish.

Creating a Service Provider for WS Federation

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

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click New > Service Provider, then specify the following details:

    Field

    Description

    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.

For information about additional configuration steps required to use this service provider, see Using Identity Server as an Identity Provider for ADFS.

If you want to use Access Manager as a WS Federation service provider, perform the following steps:

NOTE:Use this setup only in the test environment and not in the production environment.

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click New > Service Provider, then specify the following details:

    Field

    Description

    Name

    Specify a name that identifies the service provider.

    Provider ID

    https://240onbox.nam.example.com:8443/nidp/wsfed/.

    Sign-on URL

    https://240onbox.nam.example.com:8443/nidp/wsfed/ep.

    Logout URL

    https://240onbox.nam.example.com:8443/nidp/wsfed/loreply

  3. Upload the test-signing certificate.

    NOTE:You can get the test-signing certificate from Dashboard > Certificates > test-signing > Export Public Certificate > DER File.

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

Contracts Assigned to a WS Federation Service Provider

During federation, when a service provider initiates an authentication request, contract information may not be available. If the contract information is not available, Identity Server executes a default contract for validating the user. You can use the step-up authentication to assign a default contract for service providers in such scenarios.

The following scenario helps you understand the execution of contracts that are assigned to a WS Federation service provider:

Figure 4-15 Step-up authentication example with two applications

Two web applications Payroll Portal and HR Portal that are protected through different service providers use Access Manager Identity Server as an identity provider. A user wants to use the name/password form contract whenever the user accesses the HR application and wants to use the higher level contract X509 for the Payroll application. Identity Server provides ability to execute the appropriate contract that has been assigned to the service provider instead of executing the default contract.

Perform the following steps to assign a specific contract to a service provider:

  1. Click Devices > Identity Servers > Edit > WS Federation.

  2. Click the configured service provider.

  3. Go to Options > Step Up Authentication contracts and select the contracts from the Available contracts list.

NOTE:When using the service provider (SP) initiated login with a WS Federation SP, the SP configuration can impact the selection of the Access Manager contract for authentication depending on the values sent in WS Fed authentication request. To make it work properly, you must define your Access Manager contract URI to match with the request sent by the service provider.

Modifying a WS Federation Identity Provider

This section explains how to modify a WS Federation identity provider after it has been created. You can modify the following configuration details:

Renaming the Trusted Provider

  1. Click Devices > Identity Servers > Edit > WS Federation > [Provider Name].

  2. In Name, specify a new name for the trusted provider.

  3. Click OK > OK, then update Identity Server.

Configuring the Attributes Obtained at Authentication

When Identity Server creates a request to send to the identity provider, it uses the attributes that you have selected. The request asks the identity provider to provide values for these attributes. You can then use these attributes to create policies, to match user accounts, or if you allow provisioning, to create a user account on the service provider.

To select the attributes, perform the following steps:

  1. Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Attributes.

  2. (Conditional) To create an attribute set, select New Attribute Set from the Attribute Set list.

    An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at the service provider.

    1. Specify a set name, then click Next.

    2. On the Define Attributes page, click New.

    3. Select a local attribute.

    4. Specify the name of the remote attribute.

    5. For the namespace, specify http://schemas.xmlsoap.org/claims.

    6. Click OK.

    7. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    8. Click Finish.

  3. Select an attribute set.

  4. Select attributes from the Available list, and move them to the left side of the page.

  5. (Conditional) If you created a new attribute set, it must be enabled for STS.

    For more information, see Enabling the Attribute Set.

  6. Click OK, then update Identity Server.

Modifying the User Identification Method

The user identification method specifies how to identify the user.

  1. Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > User Identification.

  2. In Satisfies contract, specify the contract that is satisfied by the assertion received from the identity provider. WS Federation expects the URI name of the contract to look like a URL, so it rejects all default Access Manager contracts. You must create a contract with a URI that conforms to WS Federation requirements.

    For more information about how to create this contract, see Creating a New Authentication Contract.

  3. In Allow federation, specify whether the user can associate (federate) an account at the identity provider (the ADFS server) with an account at Identity Server.

    Enabling this option assumes that a user account exists at the provider or that a method is provided to create an account that can be associated with the user on subsequent logins. If you do not use this feature, authentication is permitted but is not associated with a particular user account.

  4. Select one of the following methods for user identification:

    • Do nothing: Allows the user to authenticate without creating an association with a user account. This option cannot be used when federation is enabled.

    • Authenticate: Allows the user to authenticate using a local account.

      • Allow ‘Provisioning’: Provides a button that the user can click to create an account when the authentication credentials do not match an existing account.

    • Provision account: Allows a new account to be created for the user when the authenticating credentials do not match an existing user. When federation is enabled, the new account is associated with the user and used with subsequent logins. When federation is not enabled, a new account is created every time the user logs in.

      This option requires that you specify a user provisioning method.

    • Attribute matching: Enables account matching. The service provider can uniquely identify a user in its directory by obtaining specific user attributes sent by the trusted identity provider. This option requires that you specify a user matching method.

      • Prompt for password on successful match: Specifies whether to prompt the user for a password when the user’s name is matched to an account, to ensure that the account matches.

  5. (Conditional) If you selected a method that requires provisioning (Allow ‘Provisioning’ or Provision account), click the Provision settings icon and create a provisioning method.

    For configuration information, see Defining the User Provisioning Method.

  6. (Conditional) If you selected Attribute matching as the identification method, click the Attribute Matching settings icon and create a matching method.

    For configuration information, see Configuring the Attribute Matching Method for Liberty or SAML 2.0.

  7. Click OK twice, then update Identity Server.

Viewing the WS Identity Provider Metadata

  1. Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata.

    The following values need to be configured accurately:

    ID: This is provider ID. The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI. The default value is urn:federation:adatum.

    sloUrl: This is the sign-on URL. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

    ssoUrl: This is the logout URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

    If the values do not match the ADFS values, you need to edit the metadata.

  2. To edit the metadata, click Edit. For configuration information, see Editing the WS Identity Provider Metadata.

  3. To view information about the signing certificate, click Certificates.

  4. Click OK > OK.

Editing the WS Identity Provider Metadata

  1. Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata > Edit.

  2. Configure the following fields:

    Provider ID: This is the provider ID. The ADFS server provides this value to the service provider in the realm parameter in the assertion. You set this value in the Properties of the Trust Policy on the ADFS server. The label is Federation Service URI. The default value is urn:federation:adatum.

    Sign-on URL: This is the sloUrl. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.

    Logout URL: This is the ssoUrl. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

  3. If you need to import a new signing certificate, click the Browse button and follow the prompts.

  4. To view information about the signing certificate, click Certificates.

  5. Click OK twice, then update Identity Server.

Modifying the Authentication Card

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

  1. Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Authentication Card.

  2. Modify the values in one or more of the following fields:

    ID: If you have need to reference this card outside of Administration Console, specify an alphanumeric value here. If you do not assign a value, Identity Server creates one for its internal use. The internal value is not persistent. Whenever Identity Server is rebooted, the value can change. A specified value is persistent.

    Text: Specify the text that is displayed on the card. This value, in combination with the image, indicates to the users the provider they are logging into.

    Image: Specify the image to be displayed on the card. Select the image from the drop-down list. To add an image to the list, click <Select local image>.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

    Passive Authentication Only: Select this option if you do not want Identity Server to prompt the user for credentials. If the user has already authenticated and the credentials satisfy the requirements of this contract, the user is passively authenticated. If the user’s credentials do not satisfy the requirements of this contract, the user is denied access.

  3. Click OK > OK, then update Identity Server.

Assertion Validity Window

You can configure the assertion validity time for WS Federation Provider (SP) to accommodate clock skew between a service provider and a SAML identity provider.

To set the assertion validity for WSFed configuration, perform the following steps:

  1. Go to Devices > Identity Servers > Edit > Options, and click New.

  2. Configure the following property:

    Property Type: WSFED ASSERTION VALIDITY

    Property Value: Specify the assertion validity time in second

  3. Restart Tomcat by using the following command:

    Linux: /etc/init.d/novell-idp restart

    Windows:

    net stop Tomcat8

    net start Tomcat8

Modifying a WS Federation Service Provider

You can modify the following configuration details:

Renaming the Service Provider

  1. Click Devices > Identity Servers > Edit > WS Federation > [Service Provider].

  2. In Name, specify a new name for the service provider.

  3. Click OK > OK, then update Identity Server.

Configuring the Attributes Sent with Authentication

When Identity Server creates a response for the service provider, it uses the attributes listed on the Attributes page. The response needs to contain the attributes that the service provider requires. If you do not own the service provider, you need to contact the administrator of the service provider and negotiate which attributes you need to send in the response. The service provider can then use these attributes to identify the user, to create policies, to match user accounts, or if it allows provisioning, to create a user account on the service provider.

  1. Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Attributes.

  2. (Conditional) To create an attribute set, select New Attribute Set from the Attribute Set list.

    An attribute set is a group of attributes that can be exchanged with the trusted provider. For example, you can specify that the local attribute of any attribute in the Liberty profile (such as Informal Name) matches the remote attribute specified at the service provider.

    1. Specify a set name, then click Next.

    2. On the Define Attributes page, click New.

    3. Select a local attribute.

    4. Specify the name of the remote attribute.

    5. For the namespace, specify http://schemas.xmlsoap.org/claims.

    6. Click OK.

    7. To add other attributes to the set, repeat Step 2.b through Step 2.e.

    8. Click Finish.

  3. Select an attribute set.

  4. Select attributes that you want to send from the Available list, and move them to the left side of the page.

  5. (Conditional) If you created a new attribute set, it must be enabled for STS.

    For more information, see Enabling the Attribute Set.

  6. Click OK, then update Identity Server.

Modifying the Authentication Response

When Identity Server sends its response to the service provider, the response can contain an identifier for the user. If you do not own the service provider, you need to contact the administrator of the service provider and negotiate whether the user needs to be identified and how to do the identification. If the service provider is going to use an attribute for user identification, that attribute needs to be in the attributes sent with authentication. See Configuring the Attributes Sent with Authentication.

To select the user identification method to send in the response, perform the following steps:

  1. Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Authentication Response.

  2. For the format, select one of the following options:

    Unspecified: Specifies that the SAML assertion contains an unspecified name identifier.

    E-mail: Specifies that the SAML assertion contains the user’s e-mail address for the name identifier.

    X509: Specifies that the SAML assertion contains an X.509 certificate for the name identifier.

  3. For the value, select an attribute that matches the format. For the Unspecified format, select the attribute that the service provider expects.

    The only values available are from the attribute set that you have created for WS Federation.

  4. To specify that this Identity Server must authenticate the user, disable the Use proxied requests option. When the option is disabled and Identity Server cannot authenticate the user, the user is denied access.

    When this option is enabled, Identity Server checks to see if other identity providers can satisfy the request. If one or more can, the user is allowed to select which identity provider performs the authentication. If a proxied identity provider performs the authentication, it sends the response to Identity Server. Identity Server then sends the response to the service provider.

  5. Set the assertion validity time for a WS Federation service provider in Assertion Validity to accommodate clock skew between the service provider and SAML Identity Server (IDP).

    There are following scenarios for setting assertion validity time:

    • The Assertion Validity set for a Service Provider overrides the assertion validity set using WSFED ASSERTION VALIDITY property in the Assertion Validity Window.

      For more information, refer Assertion Validity Window.

    • If the Assertion Validity for a Service Provider is set to 0, assertion validity set using WSFED ASSERTION VALIDITY property in the Assertion Validity Window takes precedence.

    • If the Assertion Validity is not defined for a Service Provider or in the Assertion Validity Window, by default, the token lifetime is set to 15 minutes.

  6. Click OK > OK.

  7. Update Identity Server.

Viewing the WS Federation Service Provider Metadata

  1. Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata.

    The following values need to be configured accurately:

    ID: This is provider ID. This is the value that the ADFS server provides to 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. The default value is urn:federation:treyresearch.

    sloUrl: This is the sign-on URL. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    ssoUrl: This is the logout URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

    If the values do not match the ADFS values, you need to edit the metadata.

  2. To edit the metadata, click Edit. For configuration information, see Editing the WS Federation Service Provider Metadata.

  3. To view information about the signing certificate, click Certificates.

  4. Click OK twice.

Editing the WS Federation Service Provider Metadata

  1. Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata > Edit.

  2. Configure the following fields:

    Provider ID: This is provider ID. This is the value that the ADFS server provides to 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. The default value is urn:federation:treyresearch.

    Sign-on URL: This is the sloUrl. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL. The default value is https://adfsresource.treyresearch.net/adfs/ls/.

    Logout URL: This is the ssoUrl. The default value is https://adfsresource.treyresearch.net/adfs/ls/. The ADFS server makes no distinction between the login URL and the logout URL.

  3. If you need to import a new signing certificate, click Browse and follow the prompts.

  4. To view information about the signing certificate, click Certificates.

  5. Click OK twice, then update Identity Server.

Defining Options for WS Federation Service Provider Service Provider

You can use Access Manager as an identity provider for several service providers. You can configure a specific authentication contract that is required for a service provider. If you have configured more than one authentication contract for a service provider, the contract with minimum level is selected.

When providing authentication to a service provider, Identity Server ensures that the user is authenticated by the required contract. When a user is not authenticated or when a user is authenticated, but the authenticated contracts do not satisfy the required contracts, user is prompted to authenticate with the required contract. This is called step-up authentication.

If no required contract is configured, then the default contract is executed.

Perform the following steps to define options for a WS Federation service provider:

  1. Click Devices > Identity Servers > Servers > Edit > WS Federation > Service Provider > Options.

  2. Select the required step-up authentication contracts from Available contracts and move them to the Selected contracts list. This enables the step-up authentication for the service provider.

    NOTE:Only the contract that is configured first in Selected contracts will be executed.

    Only local authentication contracts can be used for WS Federation service provider.

  3. Click OK > Apply.

Configuring STS Attribute Sets

Use the Attribute Set page to select the attribute set or sets that contain attributes the STS can provide to a relying party. An attribute set must be created before you can select it.

When creating an attribute set for the STS, you need to know which protocol you are going to use for the attribute set and select the attributes and namespace appropriate for the protocol.

  1. Click Devices > Identity Servers > Edit > WS Federation > STS Attribute Sets.

  2. To select a set, move the set from the Available attribute sets list to the Attribute sets list.

    WS Federation: There is no default attribute set for WS Federation. For information about how to create the set, see Configuring the Attributes Obtained at Authentication and Configuring the Attributes Sent with Authentication.

  3. Click OK, then update Identity Server if you have changed the configuration.

Configuring STS Authentication Methods

Use the Authentication Methods page to select the methods that can be used for authentication at the STS. The methods determine the credentials the user must supply for authentication and the user store that is used to verify the credentials. The WS Federation protocol does not use methods for authentication.

  1. Click Devices > Identity Servers > Edit > WS Federation > STS Authentication Methods.

  2. To enable a method, move the method from the Available methods list to the Methods list.

    All the methods that you have defined for Identity Server appear in the Available methods list, but the only default method that works is the Secure Name/Password-Form method. It has been extended so that it knows how to extract name and password information from a managed card that is not backed by a personal card. You can use the Secure Name/Password-Form class to create additional methods for specific user stores.

    You can also create a custom method, if required. For information, see Access Manager Developer Resources.

  3. Click OK, then update Identity Server if you have changed the configuration.

Configuring STS Authentication Request

Use the Authentication Request page to select the format for the name identifier that is returned in the SAML assertion. The selected attribute sets determine the values that are available for the formats. If you select a format but do not specify a value, a unique value is generated.

  1. Click Devices > Identity Servers > Edit > WS Federation > STS Authentication Request.

  2. Select one of the following:

    None: Indicates that the SAML assertion does not contain a name identifier.

    Unspecified: Specifies that the SAML assertion contains an unspecified name identifier. For the value, select the attribute that the relying party and the identity provider have agreed to use.

    E-mail: Specifies that the SAML assertion contains the user’s e-mail address for the name identifier. For the value, select an e-mail attribute.

    X509: Specifies that the SAML assertion contains an X.509 certificate for the name identifier. For the value, select an X.509 attribute.

  3. Click OK, then update Identity Server if you have changed the configuration.