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. Once that occurs, Access Policy Manager creates a user session and collects the user identity based on the access policy. Once the access policy successfully completes, the user identity is saved (cached) in a session database. Lastly, the WebSSO plugin retrieves (creates a proxy) the cached user credentials and authenticates the user based on the configured authentication method.
The Single Sign-On (SSO) feature provides the following benefits:
Access Policy Manager supports four 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 OAM) disables SSO for all authentication methods, and disables the current user session when you access a resource with the mis-configured SSO object. The exception is HTTP Form-based, which is the only authentication method that remains working despite the mis-configured SSO object .
The following general object attributes apply to all SSO methods.
|Name of attribute||Description||session variable supported|
|SSO method||Defines the authentication method for your SSO configuration object. You can select from the following choices: HTTP basic, Form Based, HTTP NTLMV1, HTTP 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 PREWIN2k/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, the authentication request passes through to the back end server and Websso Plugin retrieves the cached user credentials from the session database, for example, session.sso.token.last.username, session.sso.token.last.password. When indicated, the Websso Plugin performs authentication with the cached credentials on behalf of the user based upon the configured authentication methods used.|
|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 the success detection type that your authentication server uses. You can select
|Successful Logon Detection Match Value||Defines the value used by the specific success detection type.|