This section explains how to use the Liberty protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:
The Liberty Alliance is a consortium of business leaders with a vision to enable a networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information.
To accomplish its vision, the Liberty Alliance established an open standard for federated network identity through open technical specifications. In essence, this open standard is a structured version of the Security Assertions Markup Language, commonly referred to as SAML, with the goal of accelerating the deployment of standards-based single sign-on technology.
For general information about the Liberty Alliance, visit the Liberty Alliance Project Website.
Liberty resources, including specifications, white papers, FAQs, and presentations, can be found at the Liberty Alliance Resources Website.
The following table provides links to specific Liberty Alliance specifications:
Table 4-2 Liberty Alliance Links
|
Liberty Specification |
Location |
|---|---|
|
Liberty Alliance Project Overview |
|
|
Liberty White Papers |
|
|
Identity Federation Specifications |
|
|
Web Service Framework Specifications |
|
|
Liberty Profile Service Specifications |
|
|
OASIS Standards (SAML) |
You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and must be determined prior to publishing to other sites.
The profile specifies what methods of communication are available at the server for the Liberty protocol. These settings affect the metadata for the server and must be determined prior to publishing to other sites. If you have set up trusted providers, and then modify these profiles, the trusted providers need to reimport the metadata from this Identity Server.
Click Devices > Identity Servers > Edit > Liberty > Profiles.
Configure the following fields for identity providers and service providers:
Login: Specifies whether to support Artifact or Post binding for login. Select one or more of the following for the identity provider and the service provider:
The Artifact binding provides an increased level of security by using a back channel means of communication between the two servers during authentication.
The Post method uses HTTP redirection to accomplish communication between the servers.
Single Logout: Specifies the communication method to use when the user logs out. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is used if both options are selected, or if the service provider has not specified a preference.
HTTP: Uses HTTP 302 redirects or HTTP GET requests to communicate logout requests from this identity site to the service provider.
SOAP: Uses SOAP over HTTP messaging to communicate logout requests from this identity provider to the service provider.
Federation Termination: Specifies the communication channel to use when the user selects to defederate an account. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is the default setting if the service provider has not specified a preference.
HTTP: Uses HTTP 302 redirects to communicate federation termination requests from this server.
SOAP: Uses SOAP back channel over HTTP messaging to communicate logout requests from this server
Register Name: Specifies the communication channel to use when the provider supplies a different name to register for the user. Typically, you select both of these options, which enables the identity provider or service provider to accept both HTTP and SOAP requests. SOAP is the default setting if the service provider has not specified a preference.
HTTP: Uses HTTP 302 redirects to communicate federation termination requests from this server.
SOAP: Uses SOAP back channel over HTTP messaging to communicate logout requests from this server.
Click OK, then update Identity Server.
(Conditional) If you have set up trusted providers and have modified the profile, these providers need to reimport the metadata from this Identity Server.
Liberty and SAML 1.1 have the same security options for the SOAP back channel for both identity and service providers. You cannot configure the trust relationship of the SOAP back channel for Identity Server and its Embedded Service Providers.
Click Devices > Identity Servers > Edit > [Protocol].
For the protocol, select either Liberty or SAML 1.1.
Click the name of a provider.
On the Trust page, fill in the following field:
Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.
For an Embedded Service Provider, the Name option is the only available option on the Trust page.
The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.
Select one of the following security methods:
Message Signing: Relies upon message signing using a digital signature.
Mutual SSL: Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.
SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority (CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.
Basic Authentication: Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the SOAP back channel.
Send: The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.
Verify: The name and password used to verify data that the trusted provider sends.
Click OK twice.
Update Identity Server.
You can configure how Identity Server creates an authentication request for a trusted identity provider. When users authenticate, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.
The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of Identity Server.
Click Devices > Identity Servers > Edit > Liberty > [Identity Provider] > Authentication Card > Authentication Request.
Configure the federation options:
Allow Federation: Determines whether federation is allowed. The federation options that control when and how federation occurs can only be configured if the identity provider has been configured to allow federation.
After authentication: Specifies that the federation request can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally, then they can federate by using the Federate option on the card in the Login page of the Access Manager User Portal. Because the user is required to authenticate locally, you do not need to set up user identification.
During authentication: Specifies whether federation can occur when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider to complete the federation. If you enable this option, ensure that you configure a user identification method. See Selecting a User Identification Method for Liberty or SAML 2.0.
Select one of the following options for the Requested By option:
Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.
Use Types: Specifies that authentication types must be used.
Select the types from the Available types field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, Secure Name/Password, X509, Token, and so on.
Use Contracts: Specifies that authentication contracts must be used.
Select the contract from the Available contracts list. For a contract to appear in the Available contracts list, the contract must have the Satisfiable by External Provider option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity provider and the service provider. For information about contract options, see Section 4.1.4, Configuring Authentication Contracts.
Most third-party identity providers do not use contracts.
Configure the options:
Response protocol binding: Select Artifact or Post or None. Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.
If you select None, you are letting the identity provider determine the binding.
Identity Provider proxy redirects: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of None specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select Configured on IDP to let the trusted identity provider decide how many times the request can be proxied.
Force authentication at Identity Provider: Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.
Use automatic introduction: Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:
When the federated user is authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).
When the federated user is not authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.
IMPORTANT:Enable the Use automatic introduction option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.
This option must be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.
Click OK twice, then update Identity Server.
After you create a trusted service provider, you can configure how your Identity Server responds to authentication requests from the service provider.
Click Devices > Identity Servers > Edit > Liberty > [Service Provider] > Authentication Response.
Select the binding method.
If the request from the service provider does not specify a response binding, you need to specify a binding method to use in the response. Select Artifact to provide an increased level of security by using a back-channel means of communication between the two servers. Select Post to use HTTP redirection for the communication channel between the two servers. If you select Post, you might want to require the signing of the authentication requests. See Configuring the General Identity Provider Settings.
Specify the identity formats that Identity Server can send in its response. Select the Use box to choose one or more of the following:
Persistent Identifier Format: Specifies a persistent identifier that federates the user profile on the identity provider with the user profile on the service provider. It remains intact between sessions.
Transient Identifier Format: Specifies that a transient identifier, which expires between sessions, can be sent.
If the request from the service provider requests a format that is not enabled, the user cannot authenticate.
Use the Default button to specify whether a persistent or transient identifier is sent when the request from the service provider does not specify a format.
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.
Enable the Provide Discovery Services option if you want to allow the service provider to query Identity Server for a list of its web services. For example, when the option is enabled, the service provider can determine whether the Web Services Framework is enabled and which web service provider profiles are enabled.
Click OK twice, then update Identity Server.
Access Manager can be used as an identity provider for several service providers.You can configure a specific authentication contract that is required for a Service provider. If more than one authentication contract is configured for a service provider, the contract having minimum level will be 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 user is authenticated, but the authenticated contracts do not satisfy the required contracts, user will be prompted to authenticate with required contract. This is called step up authentication.
If no required contract is configured, then the default contract is executed.
NOTE:This step up authentication is supported only for Intersite Transfer Service (identity provider initiated) requests on Liberty and works for both identity and service provider initiated requests for SAML 2.0.
Click Devices > Identity Servers > Servers > Edit > Liberty > Service Provider > Options.
Select the required step up authentication contracts from the Available contracts list and move them to the Selected contracts list. This is to provide the step up authentication for the service provider.
Click OK.
Click Devices > Identity Servers > Servers > Edit > Liberty or SAML 2.0 > Identity Provider > Options.
Enable Front Channel Logout: After this option is enabled, a service provider initiates a logout at the identity provider by using the HTTP Redirect method.
Configure Front Channel Logout for Access Gateway Initiated Logout: In addition to enabling the front channel logout, configure the following property and restart tomcat:
Click Devices > Access Gateways > Edit > Reverse Proxy /Authentication > ESP Global Options. Remove the pound (#) symbol before forceESPSLOHTTP and set its value as true.
Restart Tomcat:
Linux: Enter the following command:/etc/init.d/novell-idp restart
Windows: Enter the following commands:
net stop Tomcat8
net start Tomcat8