The first two topics in this section describe two different methods for setting up federation with a SharePoint server. The next sections describe how to manage and modify WS Federation providers and configure Security Token Service (STS). STS is used to process authentication requests received at Identity Server for WS Federation.
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.
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 5-15 illustrates this configuration.
Figure 5-15 Accessing SharePoint Resources with Identity Server
In this scenario, the following events occur:
A user requests access to a SharePoint server protected by the ADFS server.
The resource sends an authentication request to the ADFS server.
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.
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.
The user is allowed to access the resource.
The following sections describe how to configure your servers for this scenario:
AD FS, Active Directory, and SharePoint servers and client are set up as described in the ADFS guide from Microsoft. See “Step-by-Step Guide for Active Directory Federation Services”.
Access Manager is set up with a site configuration that is using SSL in Identity Server's base URL. See Section 20.0, Enabling SSL Communication.
The 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 DNS of your Identity Server is idp-50.amlab.net, the URI looks 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:
Click Devices > Identity Servers > Edit > Local > Contracts > New.
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. |
Move Name/Password – Form to Methods.
Click Next and specify the following details:
Field |
Description |
---|---|
ID |
Leave this field blank. Supply a value if you want a reference to use it 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. |
Click Finish.
Continue with 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 set the contract for WS-Fed to be the default or the users must remember to click that contract every time.
Click Devices > Identity Servers > Servers > Edit > Local > Defaults.
In Authentication Contract, select the WS-Fed Contract.
Click Apply.
Continue with 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.
Click Devices > Identity Servers > Servers > Edit > General.
In the Enabled Protocols section, select WS Federation.
Click OK.
Update Identity Server.
Continue with 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.
Click Devices > Identity Server > Shared Settings > Attribute Sets > New.
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.
Click Next.
To add a mapping for the mail attribute, perform the following steps:
Click New.
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 |
Click OK.
To add a mapping for the All Roles attribute, perform the following steps:
Click New.
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 |
Click OK.
Click Finish.
Continue with 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.
Click Devices > Identity Servers > Servers > Edit > WS Federation > STS Attribute Sets.
Move the WS Federation attribute set to the Attribute sets list.
Select the WS Federation attribute set and use the up-arrow to make it first in Attribute set.
Click OK.
Update Identity Server.
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 must know the following details about the ADFS resource server:
Table 5-14 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:
Click Devices > Identity Servers > Servers > Edit > WS Federation.
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. |
Click Next, confirm the certificate, and then click Finish.
Continue with 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.
On the WS Federation page, click the name of the TreyResearch service provider.
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 Send with authentication. |
Click Apply, then click Authentication Response.
Select E-mail for the Name Identifier Format.
Select LDAP Attribute:mail [LDAP Attribute Profile] as the value for the e-mail identifier.
Click OK > OK.
Update Identity Server.
Continue with 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.
Click Devices > Identity Servers > Servers > Edit > Roles > Manage Policies.
Click New, specify a name for the policy, select Identity Server: Roles, and click OK.
On the Rule 1 page, leave Condition Group 1 blank.
With no conditions to match, this rule matches all authenticated users.
In the Actions section, click New > Activate Role.
Specify ClaimApp.
In the Actions section, click New > Activate Role.
Specify TokenApp.
Click OK > OK.
Click Apply Changes.
Click Close.
On the Roles page, select the role policy you just created, then click Enable.
Click OK.
Update Identity Server.
Continue with Importing the ADFS Signing Certificate into the NIDP-Truststore.
Access Manager 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. 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:
Click Devices > Identity Servers > Servers > Edit > Security > NIDP Trust Store > Add.
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.
Select the trusted root or certificate that you want to import and click Add Trusted Roots to Trust Stores. If there is no trusted root or certificate in the list, Import it.
Next to Trust store(s), click the Select Keystore icon.
Select the trust stores where you want to add the trusted root or certificate, then click OK > OK.
Update Identity Serve.
Configuration for Identity Server to trust the ADFS server is completed. The ADFS server must be configured to trust Identity Server. Continue with 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:
You can enable three types of claims for identity that can be enabled on an ADFS server. The claims include Common Name, Email, and User Principal Name. The ADFS step-by-step guide specifies that you do everything with a User Principal Name, which is an Active Directory convention. Although it could be given an email name that looks the same, it is not. This scenario selects to use Email instead of Common Name because Email is a more common configuration.
From the Administrative Tools, open the Active Directory Federation Services tool.
Navigate to Organizational Claims by clicking Federation Service > Trust Policy > My Organization.
Verify that Email is in this list. If it is not, move it to the list.
Navigate to your Token-based Application and enable email by right-clicking the application, editing the properties, and selecting Enabled.
Navigate to your Claims-aware Application and repeat the process.
Continue with Creating an Account Partners Configuration.
WS Federation requires a two-way trust relationship. Both identity provider and service provider must be configured to trust each other.
In the Active Directory Federation Services console, click Federation Services >Trust Policy > Partner Organizations.
Right-click Partner Organizations and select New > Account Partner.
Specify the following information in the wizard:
You do not have an account partner policy file.
For the display name, specify the DNS name of Identity Server.
For the Federation Services URI, specify https://<DNS_Name>:8443/nidp/wsfed/.
Replace <DNS_Name> with the DNS name of Identity Server. This URI is the base URL of your Identity Server with the addition of /wsfed/ on the end.
For the Federation Services endpoint URL, specify https://<DNS_Name>:8443/nidp/wsfed/ep.
Replace <DNS_Name> with the DNS name of Identity Server.
This is the base URL of your Identify Server with the addition of /wsfed/ep at the end.
For the verification certificate, import the trusted root of the signing certificate on your Identity Server.
If you have not changed it, you need the Organizational CA certificate from your Administration Console. This is the trusted root for the test-signing certificate.
Select Federated Web SSO.
Identity Server is outside of any forest, so do not select Forest Trust.
Select the Email claim.
Add the suffix that you will be using for your e-mail address.
You need to have the email end in a suffix that the ADFS server is expecting, such as @novell.com, which grants access to any user with that email suffix.
Enable this account partner.
Finish the wizard.
Continue with 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.
In the Active Directory Federation Services console, click the account partner that you created for Identity Server (see Creating an Account Partners Configuration).
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.
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.
Continue with Disabling CRL Checking.
If you are using the Access Manager certificate authority as your trusted root for the signing certificate (test-signing certificate), there is no CRL information in that certificate. However, ADFS has a mandatory requirement to perform CRL check on any certificate that they receive. For more information, see “Turn CRL checking on or off”.
Use the following information when you follow these instructions:
Create a file from the script contained at that link called TpCrlChk.vbs.
Exit the Active Directory Federation Services console.
If you do not exit the console, the console overwrites the changes made by the script file and CRL checking is not turned off.
Run the command with the following syntax:
Cscript TpCrlChk.vbs <location of ADFS>\TrustPolicy.xml "<service URI>" None
Replace <location of ADFS> with the location of the ADFS TrustPolicy.xml file. The default location is C:\ADFS\TrustPolicy.xml.
Replace <service URI> with the URI you specified in Step 3. If the DNS name of Identity Server is idp-50.amlab.net, replace it with https://idp-50.amlab.ne:8443/nidp/wsfed/.
Your command must look similar to the following:
Cscript TpCrlChk.vbs C:\ADFS\TrustPolicy.xml "https://idp-50.amlab.net:8443/nidp/wsfed/" None
In a browser on your client machine, enter the URL of the SharePoint server. For example,
https://adfsweb.treyresearch.net/default.aspx
Select the Identity Server from home realm and submit the request.
If you are not prompted for the realm, clear all cookies in the browser and try again.
Log in as a user to Access Manager Identity Server.
Verify that you can access SharePoint. If you see only a page stating Server Error in '/adfs' Application, see Enabling Logging on the ADFS Server and follow the instructions in Common Errors.
If you see the message Server Error in '/adfs' Application in the client's browser, you can verify the ADFS log file to find the cause.
To enable logging, perform the following steps:
In the ADFS console, right-click Federation Service > Properties.
Select Troubleshooting and select all options on the page.
Click OK, then look for the file that is created in the path listed in the Log files directory.
Look in that file for the reasons of the issue.
For an explanation of some of the common errors, see Common Errors.
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.
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.
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.
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 is not turned off. See Disabling CRL Checking.
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.
You can configure the ADFS server to provide authentication for a resource protected by Access Manager.
Figure 5-16 Using an ADFS Server for Access Manager Authentication
A user requests access to a resource protected by Access Gateway.
The resource sends an authentication request to Access Manager Identity Server.
Identity Server is configured to trust an ADFS server and gives the user the option of logging in to the ADFS server.
The user logs in to the ADFS server and is provided a token.
The token is sent to Identity Server.
The token satisfies the authentication requirements of the resource, and the user is allowed to access the resource.
Perform the following tasks to configure this scenario:
ADFS, Active Directory, and SharePoint servers and client are set up as described in the ADFS guide from Microsoft. See “Step-by-Step Guide for Active Directory Federation Services”.
Access Manager is set up with a site configuration that is using SSL in Identity Server's base URL. See Section 20.0, Enabling SSL Communication.
The Liberty Personal Profile is enabled.
Click Identity Servers > Edit > Liberty > Web Service Provider. Select the Personal Profile, then click Enable > Apply. Update Identity Server.
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.
Click Devices > Identity Servers > Edit.
In the Enabled Protocols section of the General Configuration page, select WS Federation.
Click OK.
Update Identity Server.
To establish 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 5-15 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. Set this value in 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 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:
Click Devices > Identity Servers > Edit > WS Federation.
Click New, select Identity Provider, and 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 login URL. For example, https://adfsaccount.adatum.com/adfs/ls/. |
Logout URL |
Specify the logout URL. For example, https://adfsresource.treyresearch.net/adfs/ls/ |
Identity Provider |
Specify the path to the signing certificate of the ADFS server. |
Confirm the certificate, then click Next.
For the authentication card, specify the following values:
Field |
Description |
---|---|
ID |
Leave this field blank. |
Text |
Specify a description that is shown to a user when the user places a 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. |
Click Finish.
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. 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.
On the WS Federation page, click the name of the Adatum identity provider configuration.
Click User Identification.
For Satisfies contract, select Name/Password – Form.
Select Allow federation.
For the User Identification Method, select Authenticate.
Click OK > OK.
Update Identity Server.
Continue with 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:
Click Devices > Identity Servers > Edit > Security > NIDP Trust Store > Add.
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.
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.
Next to Trust store(s), click the Select Keystore icon.
Select the trust stores where you want to add the trusted root or certificate and click OK > OK.
Update Identity Server.
Continue with Configuring the ADFS Server as 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.
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 Active Directory Federation Services tool.
Navigate to the Organizational Claims by clicking Federation Service > Trust Policy > My Organization.
Ensure that Email is in this list.
Navigate to Active Directory by clicking Federation Services > Trust Policy > Account Stores.
Enable the E-mail Organizational Claim:
Right-click this claim, then select Properties.
Select Enabled.
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 email address is stored.
Click OK.
Verify that the user you are going to use for authentication has an email address in the mail attribute.
Continue with 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).
In the Active Directory Federation Services console, access the Resource Partners page by clicking Federation Services > Trust Policy > Partner Organizations.
Right-click the Partner Organizations, then click New > Resource Partner.
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.
Enable this resource partner.
Finish the wizard.
To test the configuration, continue with 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 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).
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 sharing of the attribute information from Identity Server to the ADFS server. This involves creating an attribute set and enabling to send 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.
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.
Click Devices > Identity Servers > Edit > WS Federation.
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 provider. This action deletes the definition.
Enable: Enables the selected provider.
Disable: Disables the selected 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 more information, see Modifying a WS Federation Identity Provider or Modifying a WS Federation Service Provider.
Click OK.
Update Identity Server.
To set up a trust relationship, configure the ADFS server as an identity provider for Identity Server.
Click Devices > Identity Servers > Edit > WS Federation.
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 login URL. For example, https://adfsaccount.adatum.com/adfs/ls/. |
Logout URL |
Specify the logout URL. For example, https://adfsresource.treyresearch.net/adfs/ls/ |
Identity Provider |
Specify the path to the signing certificate of the ADFS server. |
Confirm the certificate and click Next.
For the authentication card, specify the following values:
Field |
Description |
---|---|
ID |
Leave this field blank. |
Text |
Specify a description. This is shown when a 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. |
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.
NOTE:Use this configuration only in the test environment and not in the production environment.
Click Devices > Identity Servers > Edit > WS Federation.
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 |
Upload the test-signing certificate of the trusted identity provider.
(Dashboard > Certificates > test-signing > Export Public Certificate > DER File > test-signing)
Click Next.
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 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. |
Click Finish.
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.
Click Devices > Identity Servers > Edit > WS Federation > New > Service Provider.
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. |
Click Next, confirm the certificate, and click Finish.
For more information, see Using Identity Server as an Identity Provider for ADFS.
NOTE:Use this configuration only in a test environment and not in a production environment.
Click Devices > Identity Servers > Edit > WS Federation > New > Service Provider.
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 |
Upload the test-signing certificate.
(Dashboard > Certificates > test-signing > Export Public Certificate > DER File > test-signing.)
Click Next, confirm the certificate, and click Finish.
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 5-17 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:
Click Devices > Identity Servers > Edit > WS Federation.
Click the configured service provider.
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.
Click Devices > Identity Servers > Edit > WS Federation > [Provider Name].
In Name, specify a new name for the trusted provider.
Click OK > OK.
Update Identity Server.
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:
Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Attributes.
(Conditional) To create an attribute set, select New Attribute Set from Attribute Set.
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.
Specify a set name, then click Next.
On the Define Attributes page, click New.
Select a local attribute.
Specify the name of the remote attribute.
For the namespace, specify http://schemas.xmlsoap.org/claims.
Click OK.
To add other attributes to the set, repeat Step 2.b through Step 2.e.
Click Finish.
Select an attribute set.
Select attributes from the Available list, and move them to the left side of the page.
(Conditional) If you created a new attribute set, it must be enabled for STS.
For more information, see Enabling the Attribute Set.
Click OK.
Update Identity Server.
The user identification method specifies how to identify the user.
Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > User Identification.
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 creating this contract, see Creating a New Authentication Contract.
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.
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.
(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.
(Conditional) If you selected Attribute matching as the identification method, click the Attribute Matching settings icon and create a matching method.
For more information, see Configuring the Attribute Matching Method for Liberty or SAML 2.0.
Click OK > OK.
Update Identity Server.
Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata.
Specify the following details:
Field |
Description |
---|---|
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 Properties of Trust Policy on the ADFS server. The label is Federation Service URI. The default value is urn:federation:adatum. |
sloUrl |
This is the login URL. This URL is listed in Properties of 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. |
To edit the metadata, click Edit. See Editing the WS Identity Provider Metadata.
To view information about the signing certificate, click Certificates.
Click OK > OK.
Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Metadata > Edit.
Specify the following details:
Field |
Description |
---|---|
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 Properties > 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 Properties of 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 login URL and logout URL. |
If you need to import a new signing certificate, click Browse and follow the prompts.
To view information about the signing certificate, click Certificates.
Click OK > OK.
Update Identity Server.
When you create an identity provider, you must configure an authentication card.
Click Devices > Identity Servers > Edit > WS Federation > [Identity Provider] > Authentication Card.
Modify the following values as required:
Field |
Description |
---|---|
ID |
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 you restart Identity Server, the value is changed. 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 |
Select the image to be displayed on the card. |
Show Card |
Determine whether the card is shown to the user. This allows a 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 a 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. |
Click OK > OK.
Update Identity Server.
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:
Go to Devices > Identity Servers > Edit > Options, and click New.
Configure the following property:
Property Type: WSFED ASSERTION VALIDITY
Property Value: Specify the assertion validity time in second
Restart Tomcat by using the following command:
/etc/init.d/novell-idp restart
For the Docker deployment, perform the following steps:
Run the kubectl get pods command to view the Access Manager pods.
Go to the Identity Server pod by running kubectl exec --namespace <name-of-the-namespace> -it pod/<name-of-the-identity-server-pod> -- sh.
Run the /etc/init.d/novell-idp restart orsystemctl restart novell-idp.service command.
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:
Click Devices > Identity Servers > Servers > Edit > WS Federation > Service Provider > Options.
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.
Click OK > Apply.
Click Devices > Identity Servers > Edit > WS Federation > [Service Provider].
In Name, specify a new name for the service provider.
Click OK > OK.
Update Identity Server.
When Identity Server creates a response for the service provider, it uses the attributes listed on the Attributes page. The response must contain the attributes that the service provider requires. If you do not own the service provider, contact the administrator of the service provider and negotiate which attributes you need to send in the response. The service provider can use these attributes to perform the following actions:
Identify a user
Create policies
Match user accounts
Create a user account on the service provider if it allows provisioning.
Perform the following steps to configure the attributes sent with authentication:
Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Attributes.
(Conditional) To create an attribute set, select New Attribute Set from Attribute Set.
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.
Specify a set name, then click Next.
On the Define Attributes page, click New.
Select a local attribute.
Specify the name of the remote attribute.
For the namespace, specify http://schemas.xmlsoap.org/claims.
Click OK.
To add other attributes to the set, repeat Step 2.b through Step 2.e.
Click Finish.
Select an attribute set.
Select attributes that you want to send from Available and move them to the left of the page.
(Conditional) If you created a new attribute set, it must be enabled for STS.
For more information, see Enabling the Attribute Set.
Click OK.
Update Identity Server.
When Identity Server sends its response to a service provider, the response can contain an identifier for the user. If you do not own the service provider, 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:
Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Authentication Response.
Select one of the following formats:
Unspecified: Specifies that the SAML assertion contains an unspecified name identifier.
E-mail: Specifies that the SAML assertion contains the user’s email address for the name identifier.
X509: Specifies that the SAML assertion contains an X.509 certificate for the name identifier.
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.
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.
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.
The minimum lifetime of a token is 600 seconds. If the Assertion Validity for a Service Provider is set to less than 300 seconds, the user must wait for the minimum lifetime period of the token to be expired.
Click OK > OK.
Update Identity Server.
Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata.
Specify the following details:
Field |
Description |
---|---|
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 Properties of 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 Properties of 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. |
To edit the metadata, click Edit. See Editing the WS Federation Service Provider Metadata.
To view information about the signing certificate, click Certificates.
Click OK > OK.
Click Devices > Identity Servers > Edit > WS Federation > [Service Provider] > Metadata > Edit.
Configure the following fields:
Field |
Description |
---|---|
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 Properties of 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. |
To import a new signing certificate, click Browse, and follow the prompts.
To view information about the signing certificate, click Certificates.
Click OK > OK.
Update Identity Server.
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.
Click Devices > Identity Servers > Edit > WS Federation > STS Attribute Sets.
To select a set, move the set from Available attribute sets to Attribute sets.
WS Federation: No default attribute is set for WS Federation. For information about creating a set, see Configuring the Attributes Obtained at Authentication and Configuring the Attributes Sent with Authentication.
Click OK and update Identity Server.
Use the Authentication Methods page to select the methods that can be used for authentication at the STS. Methods determine the credentials the user must supply for authentication and the user store that is used to verify the credentials. WS Federation does not use methods for authentication.
Click Devices > Identity Servers > Edit > WS Federation > STS Authentication Methods.
To enable a method, move the method from Available methods to Methods.
All methods that you have defined for Identity Server appear in Available methods, 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 create a custom method. For information, see Access Manager Developer Resources.
Click OK and update Identity Server.
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.
Click Devices > Identity Servers > Edit > WS Federation > STS Authentication Request.
Select one of the following options:
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.
Click OK and update Identity Server.