After you install Access Manger Appliance, an Identity Server cluster configuration is created automatically. If you install a secondary appliance, Identity Server in that server will automatically be added to Identity Server cluster.
In the Access Manager Appliance, Identity Server is automatically configured as a service that is accelerated through Access Gateway. Access Gateway in one appliance is configured to communicate only to Identity Server in the same appliance. However, Identity Servers in a cluster can internally communicate to each other through the cluster back channel.
Whether you have one machine or multiple machines in a cluster, the Access Manager software configuration process is the same. This section describes the following cluster management tasks:
This section discusses all the settings available when editing an Identity Server configuration.
An Identity Server always operates as an identity provider and can optionally be configured to run as an identity consumer (also known as a service provider), by using Liberty, SAML 1.1, SAML 2.0, or WS Federation protocols. These topics are not described in this section.
In an Identity Server configuration, you specify the following information:
The DNS name for Identity Server or clustered server site.
Certificates for Identity Server.
Organizational and contact information for the server, which is published in the metadata of the Liberty and SAML protocols.
The LDAP directories (user stores) used to authenticate users, and the trusted root for secure communication between Identity Server and the user store.
To edit an Identity Server configuration:
Click Devices > Identity Servers > Edit.
Fill in the following fields:
Name: Specify a name by which you want to refer to the configuration.
Base URL: Specifies the application path for Identity Server. Identity Server protocols rely on this base URL to generate URL endpoints for each protocol. You cannot modify the values in this field. However, you can change it by changing the DNS name of the proxy that is protecting the /nidp resource.
NOTE:If the base URL of the Identity Server is modified, all Access Manager devices that have an Embedded Service Provider need to be updated so that new metadata is imported. Reconfigure the device for a trusted relationship, then update the device. For more information about importing new metadata, see The Metadata.
Protocol: The communication protocol is HTTPS to run securely (in SSL mode) and for provisioning.
Domain: Specifies the DNS name assigned to Identity Server. When you are using an L4 switch, this DNS name must resolve to the virtual IP address set up on the L4 switch for the Identity Servers.
Port: Default port is 443.
Application: Specifies Identity Server application. The default value is nidp.
To configure session limits, fill in the following fields:
LDAP Access: Specify the maximum number of LDAP connections Identity Server can create to access the configuration store. You can adjust this amount for system performance.
Default Timeout: Specify the session timeout you want assigned as a default value when you create a contract. This value is also assigned to a session when Identity Server cannot associate a contract with the authenticated session. During federation, if the authentication request uses a type rather than a contract, Identity Server cannot always associate a contract with the request.
Limit User Sessions: Specify whether user sessions are limited. If selected, you can specify the maximum number of concurrent sessions a user is allowed to authenticate.
If you decide to limit user sessions, you must also give close consideration to the session timeout value (the default is 60 minutes). If the user closes the browser without logging out (or an error causes the browser to close), the session is not cleared until the session timeout expires. If the user session limit is reached and those sessions have not been cleared with a logout, the user cannot log in again until the session timeout expires for one of the sessions.
When you enable this option, it affects performance in a cluster with multiple Identity Servers. When a user is limited to a specific number of sessions, Identity Servers must check with the other servers before establishing a new session.
Deleting Previous User Sessions: You can configure Identity Server to delete the previous user sessions if the number of open sessions reaches the maximum limit of allowed sessions that you have specified in the Limit User Sessions field. Set the DELETE OLD SESSIONS OF USER option to true and restart Identity Server. For information about how to configure this option, see Configuring Identity Server Global Options. Previous sessions are cleared across Identity Server clusters only when a fresh authentication request comes in. When Identity Server deletes previous user sessions, it sends a logout request to the service provider through the SOAP back channel.
Use case: In this scenario, a user is accessing a protected resource from a machine and wants to access the same protected resource from another device. Identity Server will not give access to the user if the Limit User Sessions has reached a maximum limit. Identity Server must terminate the old session of the user so that the user can access the new session seamlessly.
Allow multiple browser session logout: Specify whether a user with more than one session to the server is presented with an option to log out of all sessions. If you do not select this option, only the current session can be logged out. Deselect this option in instances where multiple users log in as guests. Then, when one user logs out, none of the other guests are logged out.
When you enable this option, you must also restart any Embedded Service Providers that use this Identity Server configuration.
To configure TCP timeouts, fill in the following fields:
LDAP: Specify how long an LDAP request to the user store can take before timing out.
Proxy: Specify how long a request to another cluster member can take before timing out. When a member of a cluster receives a request from a user who has authenticated with another cluster member, the member sends a request to the authenticating member for information about the user.
Request: Specify how long an HTTP request to another device can take before timing out.
To control which protocols can be used for authentication, select one or more of the following protocols:
IMPORTANT:Enable only the protocols that you are using.
If you are using other Access Manager devices such as Access Gateway, you need to enable the Liberty protocol. Access Manager devices use an Embedded Service Provider. If you disable the Liberty protocol, you disable the trusted relationships these devices have with Identity Server, and authentication fails.
Liberty: Uses a structured version of SAML to exchange authentication and data between trusted identity providers and service providers and provides the framework for user federation.
SAML 1.1: Uses XML for exchanging authentication and data between trusted identity providers and service providers.
SAML 2.0: Uses XML for exchanging encrypted authentication and data between trusted identity providers and service providers and provides the framework for user federation.
WS Federation: Allows disparate security mechanisms to exchange information about identities, attributes, and authentication.
WS-Trust: Allows secure communication and integration between services by using security tokens.
To add capacity and to enable system failover, you can cluster a group of Identity Servers by clustering a group of Access Manager appliances. The Access Manager appliance cluster will automatically cluster the group of Identity Servers. You can also configure the cluster to support session failover, so that users don’t have to reauthenticate when an Identity Server goes down.
To enable session failover so users do not need to re-authenticate when an Identity Server goes down, see Configuring Session Failover.
To modify the name of the cluster or edit communication details, see Editing Cluster Details.
When you set up an Identity Server cluster and add more than one Identity Server to the cluster, you have set up fault tolerance. When you set up an Identity Server cluster and more than one Identity Servers are added to the cluster, you have set up fault tolerance.This ensures that if one of Identity Servers goes down, users still have access to your site because the remaining Identity Server can be used for authentication. However, it does not’ provide session failover. If a user has authenticated to the failed Identity Server, that user is prompted to authenticate and the session information is lost.
When you enable session failover and an Identity Server goes down, the user’s session information is preserved. Another peer server in the cluster re-creates the authoritative session information in the background. The user is not required to log in again and experiences no interruption of services.
An Identity Server cluster with two or more Identity Servers.
Sufficient memory on Identity Servers to store additional authentication information. When an Identity Server is selected to be a failover peer, Identity Server stores about 1 KB of session information for each user authenticated on the other machine.
Sufficient network bandwidth for the increased login traffic. Identity Server sends the session information to all Identity Servers that have been selected to be its failover peers.
All trusted Embedded Services Providers need to be configured to send the attributes used in Form Fill and Identity Injection policies at authentication. If you use any attributes other than the standard credential attributes in your contracts, you also need to send these attributes. To configure the attributes to send, click Devices > Identity Servers > Edit > Liberty > [Name of Service Provider] > Attributes.
Click Devices > Identity Servers.
In the list of clusters and Identity Servers, click the name of an Identity Server cluster.
Click the IDP Failover Peer Server Count, then select the number of failover peers you want each Identity Server to have.
To disable this feature, select 0.
To enable this feature, select one or two less than the number of servers in your cluster. For example, if you have 4 servers in your clusters and you want to allow for one server being down for maintenance, select 3 (4-1=3). If you want to allow for the possibility of two servers being down, select 2 (4-2=2).
If you have eight or more servers in your cluster, the formula 8-2=6 gives each server 6 peers. This is probably more peers than you need for session failover. In a larger cluster, you must probably limit the number of peers to 2 or 3. If you select too many peers, your machines might require more memory to hold the session data and you might slow down your network with the additional traffic for session information.
Click OK.
The failover peers for an Identity Server are selected according to their proximity. Access Manager sorts the members of the cluster by their IP addresses and ranks them according to how close their IP addresses are to the server who needs to be assigned failover peers. It selects the closest peers for the assignment. For example, if a cluster member exists on the same subnet, that member is selected to be a failover peer before a peer that exists on a different subnet.
The Cluster Details page lets you manage the configuration’s cluster details, health, alerts, and statistics.
Click Devices> Identity Servers.
Click the name of the cluster configuration.
Select from the following actions:
Details: To modify the cluster name or its settings, click Edit, then continue with Step 4.
Health: To view the health of the cluster, click the Health tab.
Alerts: To view the alerts generated by members of the cluster, click the Alerts tab.
Statistics: To view the statistics of the cluster members, click the Statistics tab.
Modify the following fields as required:
Cluster Communication Backchannel: Specify a communications channel over which the cluster members maintain the integrity of the cluster. For example, this TCP channel is used to detect new cluster members as they join the cluster, and to detect members that leave the cluster. A small percentage of this TCP traffic is used to help cluster members determine which cluster member would best handle a given request. This back channel must not be confused with the IP address/port over which cluster members provide proxy requests to peer cluster members.
Port: Specify the TCP port of the cluster back channel on all of Identity Servers in the cluster.7901 is the default TCP port.
Encrypt: Encrypts the content of the messages that are sent between cluster members.
NOTE:The Level Four Switch Port Translation feature is not required for the Access Manager Appliance as Identity Server cluster is accelerated through Access Gateway.
Port translation is enabled on switch: Specify whether the port of the L4 switch is different from the port of the cluster member. For example, enable this option when the L4 switch is using port 443 and Identity Server is using port 8443.
Cluster member translated port: Specify the port of the cluster member.
IDP Failover Peer Server Count: For configuration information, see Configuring Session Failover.
Click OK, then update Identity Server when prompted.
You can control which protocols can be used for authenticating with an Identity Server configuration. A protocol must be enabled and configured before users can use the protocol for authentication. For tight security, consider disabling the protocols that you are not going to use for authentication.
When you disable a protocol, updating Identity Server configuration is not enough. You must stop and start Identity Server.
Click Devices > Identity Servers > Edit.
In the Enabled Protocols section, select the protocols to enable
To disable a protocol, deselect it.
Click OK.
(Conditional) If you have enabled a protocol, update Identity Server.
(Conditional) If you have disabled a protocol, stop and start Identity Server.
Select Identity Server, then click Stop.
When the health turns red, select Identity Server, then click Start.
Repeat the process for each Identity Server in the cluster.
Global options are applicable for all Identity Servers in a cluster.
NOTE:Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using Administration Console.
Perform the following steps to configure Identity Server global options:
Click Devices > Identity Servers > Edit > Options.
Click New.
Set the following properties based on your requirement:
|
Property Type |
Property Value |
|---|---|
|
Allow Auth Policy Execution |
Select false to disable Identity Server to execute authorization policies. The default value is true. For example, see Executing Authorization Based Roles Policy During SAML 2.0 Service Provider Initiated Request. |
|
Cluster Cookie Domain |
Set this property to change the Domain attribute for Identity Server custer cookie. For example, see Configuring X.509 Authentication to Provide Access Manager Error Message. |
|
Cluster Cookie Path |
Set this property to change the Path attribute for Identity Server custer cookie. The default value is /nidp. For example, see Configuring X.509 Authentication to Provide Access Manager Error Message. |
|
DECODE RELAY STATE PARAM |
Select true to enable the relay state URL decoding. The default value is false. |
|
DELETE OLD SESSIONS OF USER |
Select true to enable Identity Server to delete the previous user sessions if the number of open sessions reaches the maximum limit of allowed sessions that you have specified in the Limit User Sessions field. The default value is false. |
|
HTTP ONLY CLUSTER COOKIE |
Select false to disable the HTTPOnly flags for Identity Server cluster cookies. The default value is true. |
|
IS SAML2 POST INFLATE |
Select true to enable Identity Server to receive deflated SAML 2.0 POST messages from its trusted providers. The default value is false. You can configure post binding to be sent as a compressed option by configuring this property. For example, see the note in Step 4. |
|
IS SAML2 POST SIGN RESPONSE |
Select true to enable the identity provider to sign the entire SAML 2.0 response for all service providers. |
|
LOGIN CSRF CHECK (This option is available in Access Manager Appliance 4.3 Service Pack 3 and later versions.) |
Select true to enable Cross-Site Request Forgery (CSRF) check for the Password Class and TOTP Class. This is applicable for Access Manager default pages. If you have modified any page, you must add the CSRF token to the page. To add the CSRF token, add the following: JAVA: <%String sid = request.getParameter("sid")!=null ? request.getParameter(NIDPConstants.SID) : (String)request.getAttribute(NIDPConstants.SID);NIDPSessionData sData = NIDPContext.getNIDPContext().getSession(request).getSessionData(sid);boolean csrfCheckRequired = NIDPEdirConfigUtil.isConfigured(NIDPConfigKeys.LOGIN_CSRF_CHECK.name()) ? NIDPEdirConfigUtil.getValueAsBoolean(NIDPConfigKeys.LOGIN_CSRF_CHECK.name()) : false; %> HTML: <% if (csrfCheckRequired) { %> <input type="hidden" name="AntiCSRFToken" value=" <%=sData.getAntiCSRFToken()%>"><% } %> |
|
LOGOUT IDP SESSION ON IP CHANGE (Deprecated) |
In Access Manager 4.3, this option has been merged with Advanced Session Assurance and called as Client IP. This option is listed as deprecated if you upgrade Access Manager from 4.2.x to 4.3. |
|
RENAME SESSION ID |
Select false to prevent changing the session ID automatically. The default value is true. |
|
SAML1X ATTRIBUTE MATCH BY NAME |
Select true to perform a strict check on the name space of the attributes received in assertion. For example, see Section 30.3.21, SAML 1.1 Service Provider Re-requests for Authentication. |
|
SECURE CLUSTER COOKIE |
Select false to disable the secure flags for cluster cookies. The default value is true. |
|
STS CHANGE ISSUER |
Specify the value in this format: SPentityID:UPNDomain -> new IssuerID. For example, urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/ In case of multiple child domains, add each parent domain and child domain separated by a comma. For example, if namnetiq.in is the parent domain and support.namnetiq.in and engineering.namnetiq.in are the child domains, specify the following entries: urn:federation:MicrosoftOnline:namnetiq.in -> https://namnetiq.in/nidp/wsfed/, urn:federation:MicrosoftOnline:support.namnetiq.in -> https://namnetiq.in/nidp/wsfed/, urn:federation:MicrosoftOnline:engineering.namnetiq.in -> https://namnetiq.com/nidp/wsfed/ For example, see Configuring Federation for Multiple Domains that Include Child Domains. |
|
STS OFFICE365 MULTI DOMAIN SUPPORT AUTO |
Select true to enable users to access Office 365 services by using the Issuer URI specific to the domain they belong to. The default value is false. For example, see Creating Multiple Domains in Office 365 and Establishing Federation with Access Manager. |
|
WSF SERVICES LIST |
Select full to enable users to access the Services page. Select 404 to return an HTTP 404 status code: Not Found. Select 403 to return an HTTP 403 status code: Forbidden. Select empty to return an empty services list. The default value is full. For example, see Blocking Access to the WSDL Services Page. |
|
WSFED ASSERTION VALIDITY |
Specify the assertion validity time in second for WS Federation Provider (SP) to accommodate clock skew between the service provider and SAML identity provider. The default value is 1800 seconds. For example, see Assertion Validity Window. |
|
WSTRUST AUTHORIZATION ALLOWED ACTAS VALUES |
Specify the user names who can perform ActAs operations. Allowed user names are the user accounts that the intermediate web service provider uses to authenticate with STS when sending a request with ActAs elements. You can specify more than one user name separated by a comma. For example, see Adding Policy for ActAs and OnBehalfOf. |
|
WSTRUST AUTHORIZATION ALLOWED ONBEHALF VALUES |
Specify the user names who can perform OnBehalfOf operations. Allowed user names are the user accounts that the intermediate web service provider uses to authenticate with STS when sending a request with OnBehalfOf elements. You can specify more than one user name separated by a comma. For example, see Adding Policy for ActAs and OnBehalfOf. |
|
WSTRUST AUTHORIZATION ALLOWED VALUES |
Specify the user names who can perform both ActAs and OnBehalfOf operations. You can specify more than one user name separated by a comma. For example, see Adding Policy for ActAs and OnBehalfOf. |
|
SESSION ASSURANCE USER AGENT EXCLUDE LIST |
Specify the user-agent string for that you want to disable the session validation. For example, see Disabling Advanced Session Assurance for Identity Server. |
|
SESSION ASSURANCE USER AGENT REGEX EXCLUDE LIST |
Specify the user-agent REGEX for that you want to disable the session validation. For example, see Disabling Advanced Session Assurance for Identity Server. |
|
SESSION ASSURANCE URL EXCLUDE LIST |
Specify the URL for that you want to disable the session validation. For example, see Disabling Advanced Session Assurance for Identity Server. |
|
SESSION ASSURANCE URL REGEX EXCLUDE LIST |
Specify the URL REGEX for that you want to disable the session validation. For example, see Disabling Advanced Session Assurance for Identity Server. |
|
SESSION ASSURANCE IDC COOKIE GRACEPERIOD |
Specify the time in second till which Identity Server will accept the old IDC cookie, after issuing a new cookie. The default value is 15 second. |
|
OTHER |
Specify Property Name and Property Value if you want to configure any other property. |
|
NAM_DFP_KEYS_ENFORCE_STRICT |
When Advanced Session Assurance is enabled, specify true to send session keys only the first time when the device information is fetched. Specify false to send session keys every time whenever device information is fetched. The default value is false. You can configure this property by clicking OTHER. |
Click OK > Apply.