Access Policy Manager® provides a Single Sign-On (SSO) feature that leverages the credential caching and credential proxying technology.
Credential caching and proxying is a two-phase security approach that allows your users to enter their credentials once to access their secured web applications. By leveraging this technology, users request access to the secured back-end web server. After that occurs, Access Policy Manager creates a user session and collects the user identity based on the access policy. When the access policy successfully is complete, the user identity is saved (cached) in a session database. Access Policy Manager subsequently reuses the cached identity to seamlessly log the user into the secured web applications, thus providing the user with a single sign on experience.
The Single Sign-On (SSO) feature provides the following benefits:
Access Policy Manager supports various SSO methods. Each method contains a number of attributes that you need to configure properly to support SSO.
Mis-configuring SSO objects for any of these authentication methods (HTTP Basic, NTLM v1 and v2, and Kerberos) could disable SSO for all authentication methods for a user's session when the user accesses a resource with the mis-configured object. The exception is Form Based, which is the only SSO method that is not disabled when any other method fails due to a mis-configured SSO object.
Of these general attributes, the Username source attribute applies to all SSO methods.
|Name of attribute||Description||Session variable defaults|
|SSO method||Defines the authentication method for your SSO configuration object. You can select from the following choices: HTTP Basic, Form Based, NTLMV1, NTLMV2, or Kerberos.||N/A|
|Username Source||Defines the source session variable name of the user name for SSO authentication.||session.sso.token.last.username|
|Password Source||Defines the source session variable name of the password for SSO authentication.||session.sso.token.last.password|
|Username Conversion||Converts pre-Windows 2000/UPN username input format to the format you want to use for SSO. For example, convert domain\username or username@domain to username.||session.sso.domain.source|
The following object attributes apply specifically to HTTP Form-Based SSO method.
|Name of Attribute||Description||Session Variable Supported|
|Start URI||Defines the start URI value. HTTP form-based authentication executes for SSO if the HTTP request URI matches the start URI value. You can specify multiple start URI values in multiple lines for this attribute. You can specify one wildcard asterisk [*] in the value for wildcard matching.||start_uri|
|Pass Through||If you check this box, cookies presented in the form will be propagated to the client browser.|
|Form Method||Defines the method of the HTTP form-based authentication for SSO. The options are GET or POST. By default, the form method value is set to POST. However, if you specify GET, the SSO authentication converts as HTTP GET request.|
|Form Action||Defines the form action URL used for HTTP authentication request for SSO. For example, /access/oblix/apps/webgate/bin?/webgate.dll. If you do not specify a value for this attribute, the original request URL is used for SSO authentication.||form_action|
|Form Parameter For User Name||Defines the parameter name of the login user name. For example, the user ID is specified as the attribute value if the HTTP server expects the user name in the form of userid=.||form_parameter|
|Form Parameter for Password||Defines the name of the login password. For example, Pass is specified as the attribute value if the HTTP server expects the password in the form of pass=.|
|Hidden Form Parameters/Values||Defines the hidden form parameters required by the authentication server login form at your location. You must enter hidden parameters, like this: param1 value1 param2 value2. Separate each parameter's name and value by a space, and not by an equal sign. Each parameter must start on a new line.|
|Successful Logon Detection Match Type||Defines how Access Policy Manager detects whether the user was successfully
authenticated by the server. You can select one:
|Successful Logon Detection Match Value||Defines the value used by the specific success detection type; that is, the redirect URL or cookie name.|