Manual Chapter : Single Sign-On Methods

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0
Manual Chapter

Single Sign-On Methods

What is Single Sign-On?

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 asks 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 completes successfully, 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:
  • Eliminates the need to administer and maintain multiple user logins
  • Eliminates the need for users to enter their credentials multiple times.

What are the supported SSO methods?

Access Policy Manager supports the following SSO authentication methods.
SSO method
Description
HTTP Basic
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.
NTLMV1
NTLM version 1 employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to the server.
NTLMV2
NTLM version 2 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.
Form Based
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.
Forms - Client Initiated
Upon detection of the request for logon page (URI, header, or cookie that is configured for matching the request), Access Policy Manager generates JavaScript code, inserts it into the logon page and returns the logon page to the client, where it is automatically submitted by inserted JavaScript. APM processes the submission and uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.
OAuth Bearer
The OAuth Bearer provides an access token to the backend server. You can configure OAuth single sign-on as passthrough (where the JWT token is received by other means) or have APM generate and sign the token.
SAML
A SAML IdP service is a type of single sign-on (SSO) authentication service in APM that provides SSO authentication for external SAML service providers (SPs). You specify a SAML IdP service when you use a BIG-IP system as a SAML identity provider (IdP). Configure SAML under
Federation
.

About the Single Sign-On configuration objects

Access Policy Manager supports various SSO configurations. Each configuration contains a number of attributes that you need to specify correctly to support SSO.
Misconfiguring SSO objects for HTTP Basic, NTLM v1 and v2, Kerberos, and OAuth Bearer could disable SSO for all authentication methods in a user's session when the user accesses a resource using the misconfigured SSO configuration. The exceptions are Forms and Forms - Client Initiated; these are the only SSO methods that are not disabled when any other method fails due to a misconfigured SSO object.

Creating an HTTP Basic SSO configuration

With the HTTP Basic method of authentication, the SSO plug-in uses the cached user identity and sends the request with the authorization header. This header contains the Basic token and the base64-encoding of the user name, colon, and the password.
  1. On the Main tab, click
    Access
    Single Sign-On
    HTTP Basic
    .
    The HTTP Basic screen opens.
  2. Click
    Create
    .
    The New SSO Configuration screen opens.
  3. In the
    Name
    field, type a name for the SSO configuration.
    The maximum length of a single sign-on configuration is 225 characters, including the partition name.
  4. From the
    Log Setting
    list, select one of the following options:
    • Select an existing APM log setting.
    • Click
      Create
      to create a new log setting.
  5. In the Credentials Source area, specify the credentials that you want cached for Single Sign-On.
  6. In the SSO Method Configuration area, specify the relevant settings.
  7. Click
    Finished
    .

HTTP Basic SSO configuration settings

These settings are available when you create an HTTP Basic SSO configuration.

General Properties settings for HTTP Basic SSO configuration

Setting
Value
Additional Information
General Properties
Basic
or
Advanced
. Defaults to
Basic
.
Additional settings are available when you select
Advanced
.
Name
Name of the SSO configuration.
The name must begin with a letter, or underscore, and contain only letters, numbers, underscores, dashes, and periods. Maximum length including the partition name is 225 characters. Avoid using global reserved words in the name, such as all, delete, disable, enable, help, list, none, show, or None.
Headers
Header name-value pairs to send with the SSO method.
Available when you select
Advanced
from the
General Properties
list.
Log Settings
Settings for the access event logs. Default is to use settings in the access profile.
To create custom log settings, click + .

Credentials Source settings for HTTP Basic SSO configuration

Setting
Value
Additional Information
Username Source
Specifies the user name to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.username
Password Source
Specifies the password to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.password

SSO configuration settings for HTTP Basic SSO configuration

Setting
Value
Additional Information
Username Conversion
This check box is clear by default.
Select the check box to convert the PREWIN2k/UPN user name input format to the format you want to use for SSO. For example, convert
domain\username
or
username@domain
to
username
.

Creating an HTTP forms-based SSO configuration

With the HTTP forms method of authentication, upon detection of the start URL match, the SSO plug-in uses the cached user identity to construct and send the HTTP form-based POST request on behalf of the user.
  1. On the Main tab, select
    Access
    Single Sign-On
    Form Based
    .
    The Form Based screen opens.
  2. Click
    Create
    .
    The New SSO Configuration screen opens.
  3. In the
    Name
    field, type a name for the SSO configuration.
    The maximum length of a single sign-on configuration is 225 characters, including the partition name.
  4. From the
    Use SSO Template
    list, select the template you want to use.
    The screen refreshes to show additional settings applicable to the specific template.
  5. In the Credentials Source area, specify the credentials that you want cached for Single Sign-On.
  6. If you selected
    None
    from the
    Use SSO Template
    list, fill in the relevant settings in the SSO Method Configuration area.
    Otherwise, these settings are taken from the template that you selected.
  7. From the
    Log Setting
    list, select one of the following options:
    • Select an existing APM log setting.
    • Click
      Create
      to create a new log setting.
  8. Click
    Finished
    .

HTTP Form Based SSO configuration settings

These settings are available when you create an HTTP form-based SSO configuration.

General Properties settings for HTTP form-based SSO configuration

Setting
Value
Additional Information
General Properties
Basic
or
Advanced
. Defaults to
Basic
.
Additional settings are available when you select
Advanced
.
Name
Name of the SSO configuration.
The name must begin with a letter, or underscore, and contain only letters, numbers, underscores, dashes, and periods. Maximum length including the partition name is 225 characters. Avoid using global reserved words in the name, such as all, delete, disable, enable, help, list, none, show, or None.
Use SSO Template
If you select
None
, you must fill in the SSO Method Configuration area. Otherwise, the SSO Method Configuration area is not available; settings are configured with data supplied by the template you select.
Headers
Header name-value pairs to send with the SSO method.
Available when you select
Advanced
from the
General Properties
list.
Log Settings
Settings for the access event logs. Default is to use settings in the access profile.
To create custom log settings, click + .

Credentials Source settings for HTTP form-based SSO configuration

Setting
Value
Additional Information
Username Source
Specifies the user name to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.username
Password Source
Specifies the password to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.password

SSO configuration settings for HTTP form-based SSO configuration

Setting
Value
Additional Information
Destination (IP or Hostname)
Defines the IP address or fully qualified domain name for the OWA server.
Displays only when you select an SSO template for OWA.
Start URI
Defines the start URI value. HTTP form-based authentication executes for SSO if the HTTP request URI matches the start URI value.
Multiple start URI values in multiple lines can be entered for this attribute.
Supported session variable:
start_uri
Pass Through
If you select the
Enable
check box, cookies presented in the form propagate to the client browser. Defaults to cleared.
Form Method
Defines the SSO authentication method :
GET
or
POST
. Defaults to
POST
.
If you specify
GET
, the SSO authentication method is 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 left blank, the original request URL is used for SSO authentication.
Supported session variable:
form_action
Form Parameter For User Name
Defines the parameter name of the logon 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=
.
Supported session variable:
form_parameter
Form Parameter for Password
Defines the name of the logon 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 logon form at your location.
Specify a parameter name, a space, and the parameter value, if any. Each parameter must start on a new line. This example includes parameters for
platform
and
language
.
platform %{session.client.platform}
language American English
When using a session variable as a value, precede it with a percent (%) sign and enclose it in curly braces ({}).
Successful Logon Detection Match Type
Defines how Access Policy Manager detects whether the user was successfully authenticated by the server. Defaults to
None
. You can select one option.
  • None
    No check is made for authentication success.
  • By Resulting Redirect URL
    Authentication success is checked for by examining the redirect URL from the HTTP response. Multiple values can be specified for this option.
  • By Presence Of Specific String in Cookie
    Authentication success is checked for by searching for the string in the response.
    Supported session variable:
    success_match_value
Successful Logon Detection Match Value
Defines the value for the specific success detection type: the redirect URL or cookie name.
For
By Resulting Redirect URL
, you can specify multiple URLs and the system supports a single instance of the wildcard character (*) in a URL.

Creating an NTLMV1 SSO configuration

The NTLM authentication method employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to a server.
  1. On the Main tab, click
    Access
    Single Sign-On
    NTLMV1
    .
    The NTLMV` screen opens.
  2. Click
    Create
    .
    The New SSO Configuration screen opens.
  3. In the
    Name
    field, type a name for the SSO configuration.
    The maximum length of a single sign-on configuration is 225 characters, including the partition name.
  4. From the
    Log Setting
    list, select one of the following options:
    • Select an existing APM log setting.
    • Click
      Create
      to create a new log setting.
  5. In the Credentials Source area, specify the credentials that you want cached for Single Sign-On.
  6. In the SSO Method Configuration area, specify the relevant settings.
  7. Click
    Finished
    .

NTLMV1 SSO configuration settings

These configuration settings are available when you configure an NTLMV1 SSO method.

General Properties settings for NTLMV1 SSO configuration

Setting
Value
Additional Information
General Properties
Basic
or
Advanced
. Defaults to
Basic
.
Additional settings are available when you select
Advanced
.
Name
Name of the SSO configuration.
The name must begin with a letter, or underscore, and contain only letters, numbers, underscores, dashes, and periods. Maximum length including the partition name is 225 characters. Avoid using global reserved words in the name, such as all, delete, disable, enable, help, list, none, show, or None.
Headers
Header name-value pairs to send with the SSO method.
Displayed when you select
Advanced
from the
General Properties
list.
Log Settings
Settings for the access event logs. Default is to use settings in the access profile.
To create custom log settings, click + .

Credentials Source settings for NTLMV1 SSO configuration

Setting
Value
Additional Information
Username Source
Specifies the user name to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.username
Password Source
Specifies the password to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.password
Domain Source
Specifies the domain to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.logon.last.domain

SSO configuration settings for NTLMV1 SSO configuration

Setting
Value
Additional Information
Username Conversion
Check box is cleared by default.
Select the check box to convert the PREWIN2k/UPN user name input format to the format you want to use for SSO. For example, convert
domain\username
or
username@domain
to
username
.
NTLM Domain
Specifies the name of the domain where all users and groups are authenticated.
Specifies a domain name.

Creating an NTLMV2 SSO configuration

With this method of authentication, NTLM employs a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to a server. This version of NTLM has been updated from version 1.
  1. On the Main tab, click
    Access
    Single Sign-On
    NTLMV2
    .
    The NTLMV2 screen opens.
  2. Click
    Create
    .
    The New SSO Configuration screen opens.
  3. In the
    Name
    field, type a name for the SSO configuration.
    The maximum length of a single sign-on configuration is 225 characters, including the partition name.
  4. From the
    Log Setting
    list, select one of the following options:
    • Select an existing APM log setting.
    • Click
      Create
      to create a new log setting.
  5. In the Credentials Source area, specify the credentials that you want cached for Single Sign-On.
  6. In the SSO Method Configuration area, specify the relevant settings.
  7. Click
    Finished
    .

NTLMV2 SSO configuration settings

These configuration settings are available when you configure an NTLMV2 SSO method.

General Properties settings for NTLMV2 SSO configuration

Setting
Value
Additional Information
General Properties
Basic or
Advanced
. Defaults to
Basic
.
Additional settings are available when you select
Advanced
.
Name
Name of the SSO configuration.
The name must begin with a letter, or underscore, and contain only letters, numbers, underscores, dashes, and periods. Maximum length including the partition name is 225 characters. Avoid using global reserved words in the name, such as all, delete, disable, enable, help, list, none, show, or None.
Headers
Header name-value pairs to send with the SSO method.
Displayed when you select
Advanced
from the
General Properties
list.
Log Settings
Settings for the access event logs. Default is to use settings in the access profile.
To create custom log settings, click + .

Credentials Source settings for NTLMV2 SSO configuration

Setting
Value
Additional Information
Username Source
Specifies the user name to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.username
Password Source
Specifies the password to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.sso.token.last.password
Domain Source
Specifies the domain to cache for single sign-on. Defaults to a session variable.
Supported session variable:
session.logon.last.domain

SSO configuration settings for NTLMV2 SSO configuration

Setting
Value
Additional Information
Username Conversion
Check box is cleared by default.
Select the check box to convert the PREWIN2k/UPN user name input format to the format you want to use for SSO. For example, convert
domain\username
or
username@domain
to
username
.
NTLM Domain
Specifies the name of the domain where all users and groups are authenticated.
Specifies a domain name.

About NTLMv2 SSO failure for an invalid HTTP 401 response

If an HTTP 401 response from a server includes more than one
www-authenticate: NTLM
header, NTLMv2 SSO fails. This is expected behavior. An HTTP 401 response should contain only one
www-authenticate: NTLM
header.