Access Policy Manager® supports the following SSO authentication methods.
|HTTP Basic Auth||Access Policy Manager uses the cached user identity and sends the request with the authorization header. This header contains the token Basic and the base64-encoded for the user name, colon, and the password.|
|HTTP Forms||Upon detection of the start URL match, Access Policy Manager uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.|
|HTTP NTLM Auth v1||NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to the server.|
|HTTP NTLM Auth v2||NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to the server. This version of NTLM is an updated version from NTLM v1.|
|Kerberos||This provides transparent authentication of users to Windows Web application servers (IIS) joined to Active Directory domain. It is used when IIS servers request Kerberos authentication; this SSO mechanism allows the user to get a Kerberos ticket and have Access Policy Manager present it transparently to the IIS application.|
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 exceptions are Forms and Forms - Client Initiated, which are the only SSO methods that are 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 the HTTP Forms 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. s||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 method becomes an 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.|