Manual Chapter : Single Sign-On

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 7.1.0
Manual Chapter

Single Sign-On

About single sign-on profiles

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?

BIG-IQ Centralized Management supports the following Single Sign-On (SSO) authentication methods.
SSO method
Description
HTTP Basic
BIG-IQ 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, BIG-IQ uses the cached user identity to construct and send the HTTP form-based post request on behalf of the user.
HTTP Forms - Client Initiated
Upon detection of the request for logon page (URI, header, or cookie that is configured for matching the request), BIG-IQ 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. BIG-IQ processes the submission and 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 BIG-IQ present it transparently to the IIS application.
OAuth bearer
You can create an OAuth bearer SSO configuration to allow single-sign on using an OAuth token that BIG-IQ has received or validated from an external OAuth authorization server.

Create 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. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    HTTP Basic
    .
  4. This screen displays the HTTP Basic SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    A new SSO configuration screen will open.
  6. From the
    General Properties
    drop down list, select
    Basic
    or
    Advanced
    .
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. For
    Headers
    , in the
    Name
    and
    Value
    fields, type a header name-value pair to send with the SSO method.
  10. From the
    Log Settings
    drop down list, select the log setting created from event logs. This field is available for configuration for Access Groups running BIG-IP version 13.0 and later.
  11. In
    Username Source
    , type user name you want cached for single sign-on.
  12. In
    Password Source
    , type the password you want cached for single sign-on.
  13. For
    Username Conversion
    , click 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
    .
  14. You can view the
    Ephemeral Authentication
    field for Access Groups managing devices running BIG-IP version 15.1 and later. Select the drop down menu to view the
    Authentication Configuration
    associated with this HTTP Basic SSO configuration. Please configure Privileged User Access with Ephemeral Authentication (temporary passwords) on a source BIG-IP device, then re-import the changes to BIG-IQ to deploy them to your target devices. Refer to the BIG-IP documentation on support.f5.com to learn more about creating Ephemeral Authentication configurations.
  15. Click
    Save & Close
    .
The HTTP basic SSO object will display in the HTTP Basic SSO list.

Create an NTLMV1 SSO configuration

You configure NTLM authentication to employ a challenge-response mechanism for authentication, where the users can prove their identities without sending a password to a server.
  1. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    NTLMV1
    .
  4. This screen displays the NTLMV1 SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    A new SSO configuration screen will open.
  6. From the
    General Settings
    list, select
    Basic
    or
    Advanced
    .
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. For
    Headers
    , type a header name-value pair to send with the SSO method.
  10. For
    Log Settings
    , select the log setting created from event logs.
  11. For
    Username Source
    , type the user name you want cached for single sign-on.
  12. For
    Password Source
    , type the password you want cached for single sign-on.
  13. To convert the PREWIN2k/UPN user name input format to the format you want to use for SSO, select the
    Username Conversion
    check box.
  14. Type the location of the
    NTLM Domain
    where all users and groups are authenticated.
  15. To save your changes, click the
    Save & Close
    button at the bottom of the screen.
The NTLMV1 SSO object is created, and displays in the NTLMV1 list.

Create an NTLMV2 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. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    NTLMV2
    .
  4. This screen displays the NTLMV2 SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    A new SSO configuration screen will open.
  6. From the
    General Settings
    list, select
    Basic
    or
    Advanced
    .
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. For
    Headers
    , type a header name-value pair to send with the SSO method.
  10. For
    Log Settings
    , select the log setting created from event logs.
  11. For
    Username Source
    , type the user name you want cached for single sign-on.
  12. For
    Password Source
    , type the password you want cached for single sign-on.
  13. To convert the PREWIN2k/UPN user name input format to the format you want to use for SSO, select the
    Username Conversion
    check box.
  14. For
    NTLM Domain
    , type the location of the domain where all users and groups are authenticated.
  15. To save your changes, click the
    Save & Close
    button at the bottom of the screen.
The NTLMV2 SSO object displays in the NTLMV2 list.

Create a Kerberos SSO configuration

Create a Kerberos single-sign to allow the end-user to obtain a Kerberos ticket and have Access Policy Manager present it transparently to Microsoft's IIS application.
  1. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    Kerberos
    .
  4. From the
    General Settings
    drop down list, select
    Basic
    or
    Advanced
    .
  5. This screen displays the Kerberos SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  6. Click
    Create
    . A new Kerberos SSO Configuration screen will open.
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. For
    Headers
    , in the
    Name
    and
    Value
    fields, type a header name-value pair to send with the SSO method.
  10. From the
    Log Settings
    drop down list, select the log setting created from event logs. This field is available for configuration for Access Groups running BIG-IP version 13.0 and later.
  11. In
    Username Source
    , type user name you want cached for single sign-on.
  12. In
    Password Source
    , type the password you want cached for single sign-on.
  13. For
    Username Conversion
    , click the check box to convert the PREWIN2k/UPN user name input format to the format you want to use for SSO. This field is available for configuration for Access Groups running BIG-IP version 13.1 and later.
    For example, convert
    domain\username
    or
    username@domain
    to
    username
    .
  14. For
    KDC
    , IP Address or host name of the Kerberos Key Distribution Center (KDC) for the server's realm.
    This is normally an Active Directory domain controller. If you leave this empty, the KDC must be discoverable through DNS.
  15. For
    UPN Support
    , click the check box to enable the UPN suffix support for Kerberos SSO when integrating into Microsoft Active Directory infrastructure.
  16. For
    Account Name
    , type the name of the Active Directory account configured for delegation.
    This account must be configured in the server's Kerberos realm (AD Domain).
  17. For
    Account Password
    , type the password for the delegation account specified in the previous field.
  18. For
    Confirm Account Password
    , re-type the password for the delegation account specified in the previous field.
  19. For
    SPN Pattern
    , you can use this optional field to modify how the Service Principal Name (SPN) for the servers is constructed. Leave this field empty unless you need a non-standard SPN format. To make modifications, you can create entries from the choices below.
    • HTTP/%h@REALM
      with
      REALM
      replaced by the actual realm name as specified in the Kerberos Realm field. The
      %h
      option takes the hostname from the HTTP request Host header.
    • HTTP/%s@REALM
      with
      REALM
      replaced by the actual realm name as specified in the Kerberos Realm field. The
      %s
      option takes the hostname discovered through reverse DNS lookup using the server IP address.
  20. For
    Ticket Lifetime
    , type in minutes (for example, 600 minutes equates to 10 hours), the lifetime of Kerberos tickets obtained for the user.
    The value represents the maximum ticket lifetime, and the actual lifetime may be less by up to 1 hour.
  21. From the
    Ticket Lifetime
    drop down list, select when specify when to submit a Kerberos ticket to the application server. Choose from the following options.
    • Always
      . The Authorization header with a Kerberos ticket is inserted into every HTTP request whether it requires authentication or not.
    • On 401 Status Code
      . The system first forwards the user's HTTP request to the web server without inserting a new Authorization header (but any browser's Authorization header will be deleted).
  22. Click
    Save & Close
    .

Create an HTTP form-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. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    Form Based
    .
  4. This screen displays the HTTP Form Based SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    A new HTTP form-based SSO configuration will open.
  6. From the
    General Settings
    list, select
    Advanced
    .
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. From the
    Use SSO Template
    list, select from the available templates, or select
    None
    to create a configuration without relying on a template.
    After selecting
    None
    or another template, fill in the SSO Method configuration form.
  10. In the
    Name
    and
    Value
    fields for
    Headers
    , type a header name-value pair to send with the SSO method.
    Select
    +
    to add additional header name-value pair fields.
  11. For
    Log Settings
    , select the log setting you want to use. This field is available for configuration for Access Groups running BIG-IP version 13.0 and later.
  12. In the
    Username Source
    and
    Password Source
    fields, type the user name you want cached for single sign-on.
  13. For
    Password Source
    , type the password you want cached for single sign-on.
  14. For
    Destination (IP or Hostname)
    , type the IP address or fully qualified domain name for the OWA server.
    Displays when you select an OWA SSO template.
  15. For
    Start URI
    , type a URL resource.
    For example, for OWA, it would be
    /owa/auth/logon.aspx*
    . For Citrix,it would be
    /Citrix/XenApp/auth/logon.aspx
    . This resource must respond with a challenge to a non-authenticated request.
  16. Select the
    Pass Through
    check box to propagate cookies present in this form to the client browser.
  17. Select the
    Form Method
    you want to use for the form-based HTTP authentication.
  18. Type the complete destination URL to process the form in the
    Form Action
    field.
    This specifies the form action URL that is used for HTTP form-based authentication.
  19. For
    Form Parameter For User Name
    , type the parameter name used by the form to which you are sending the POST request.
  20. For
    Form Parameter For Password
    , type the parameter name used by the form to which you are sending the POST request.
  21. For
    Hidden Form Parameters/Values
    , type the hidden form parameters required by the authentication server logon form at your location.
    Each parameter must start on a new line. Type a parameter name, a space, and the parameter value, if any.
  22. For
    Ticket Lifetime
    , type, in minutes (for example, 600 minutes equates to 10 hours), the lifetime of Kerberos tickets obtained for the user.
  23. You can view the
    Ephemeral Authentication
    field for Access Groups managing devices running BIG-IP version 15.1 and later. Select the drop down menu to view the
    Authentication Configuration
    associated with this form-based SSO configuration. Please configure Priviledged User Access with Ephemeral Authentication (temporary passwords) on a source BIG-IP device, then reimport the changes to BIG-IQ to deploy them to your target devices. Refer to the BIG-IP documentation on support.f5.com to learn more about creating Ephemeral Authentication configurations.
  24. To save your changes, click the
    Save & Close
    button at the bottom of the screen.
The HTTP form-based SSO object will display in the Form Based list.

Create an HTTP forms client-initiated SSO configuration

The HTTP forms client-initiated authentication method supports web applications that run JavaScript in the browser and need to maintain application state during the logon process, and supports web applications that present multiple logon screens.
  1. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    Forms - Client Initiated
    .
  4. This screen displays the HTTP forms client-initiated SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    A new SSO configuration screen will open.
  6. Click
    GENERAL SETTINGS
    .
  7. Type an
    SSO Configuration Name
    . You cannot change the name of an existing profile. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. Type an optional
    SSO Configuration Description
    .
  10. Select the
    Log Setting
    you want to use.
  11. Click
    FORM SETTINGS
    .
  12. For
    Passthrough Configuration
    , select whether the SSO object does not require any form configuration when passthrough is selected. If passthrough is off, configure at least one form.
  13. Type the
    Form Name
    and optional
    Form Description
    .
  14. For
    Detect request for form by
    , select which element of the HTTP request headers to use to identify the application request for logon page:
    Cookie
    ,
    Header
    , or
    URI
    .
  15. For
    Request URI
    , type a URI that the system identifies as the form by a successful match (default) or failed match (configurable with Advanced Properties) against one or multiple URIs.
  16. For
    Request Method
    , select whether the request method is
    GET
    or
    POST
    .
  17. Select the
    Request Negative
    check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  18. Select the
    Request Prefix
    check box to specify that the system matches on a partial string.
  19. For
    Identity Form by
    , select how to find the HTML logon form in the HTML body of the logon page.
  20. For
    Form Parameters Settings
    , specify that the form parameters that have already been defined are used to find the form.
  21. For
    Disable Auto detect submit
    , the default is
    No
    .
  22. The
    Scheme
    option is available when
    Disable Auto detect
    submit is set to
    Yes
    . Select how to detect a submit.
  23. For
    Submit Request Negative
    , click the check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  24. For
    Submit Request Prefix
    , click the check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  25. For
    Detect Login By
    , select whether and how to detect a successful logon.
  26. For
    Injection Method
    , select whether to use the default JavaScript that the system creates.
  27. Click
    HEADER SETTINGS
    .
  28. For
    Headers in the SSO Configuration
    , add a header by typing a header name and header value. Form headers are optional.
The HTTP form client-initiated object will display in the HTTP Form Client-Initiated list.

Create an OAuth bearer SSO configuration

Create an OAuth bearer SSO configuration when you want to allow single-sign on using an OAuth token that BIG-IQ has gotten or validated from an external OAuth authorization server.
  1. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. Expand
    SINGLE SIGN-ON
    and click
    OAuth Bearer
    .
  4. This screen displays the OAuth Bearer SSO configurations in the working configuration for the Access group.
    • To create an SSO object, click the
      Create
      button.
    • To delete an SSO object, select the check box next to the object and click the Delete button.
  5. Click
    Create
    .
    The new SSO Configuration screen will open.
  6. From the
    General Settings
    list, select
    Basic
    or
    Advanced
    .
  7. Enter a
    Name
    for this SSO configuration. Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None. You cannot change the name if you are editing an existing configuration.
  8. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  9. For
    Headers
    , type a header name-value pair to send with the SSO method.
  10. For
    Log Settings
    , select the log setting created from event logs.
    By default, BIG-IQ uses the log settings specified in the access profile. You can also create custom log settings or use the
    default-log-setting
    for this SSO configuration. Click
    +
    to create custom settings.
  11. Send Token
    is available for configuration for Access Groups running BIG-IP version 14.1 and later. Select when to send the token:
    • To always send the token, select
      Always
      .
    • To send the token when you receive a 4xx response from the server, select
      On 4xx Response
      and choose one or more 4xx responses.
  12. For
    Log Settings
    , select the log settings to use for the access event logs.
    By default, the log settings specified in the access profile are used. You can also create custom log settings or use the
    default-log-setting
    for this SSO configuration. Click
    +
    to create custom settings.
  13. If you select
    Passthrough
    , select a previously created
    OAuth server
    .
  14. To generate a token, select
    Generate JWT
    for
    Token Source
    . This option is available for configuration for Access Groups running BIG-IP version 14.1 and later.
    1. For
      Issuer
      , type the URL for the JWT issuer.
      For example,
      https://jwt-issuer.com
      .
    2. In
      Subject
      , retain the default value, %{session.assigned.uuid}, or type a subject for the JWT.
    3. Click
      Enable Token Cache
      to increase performance until the cached JWT expires.
    4. For
      Access Token Lifetime
      , type the number of minutes you want the JWT access token to be considered valid.
    5. For
      Signing Key
      , select the JWK key configuration previously created for signing the token.
    6. For
      Audience
      , add the audience claim or claims for which the JWT access token is intended. Each value in this list can be a string, URI, or session variable.
    7. For
      Scope
      , type one or more space-separated scope strings (using the ASCII character set) or session variables.
    8. If you created claims for the token, for
      JWT Claims
      , move the previously created claims you want to use to the
      Selected
      list.
  15. Click
    Save & Close
    .
The OAuth bearer object will display in the OAuth Bearer list.

Configure an SSO profile

Configure an SSO profile to set up the BIG-IQ system for single sign-on. A SSO profile may be attached to a virtual server, and may be assigned to an SSO configuration during creation.
  1. At the top of the screen, select
    Configuration
    , then on the left side of the screen, click
    ACCESS
    Access Groups
    .
  2. Click the name of an Access group.
    A new screen displays the group's properties.
  3. On the left, expand
    SINGLE SIGN-ON
    and click
    SSO Profiles
    .
  4. This screen displays the SSO profiles in the working configuration for the Access group.
    • To configure the properties of an SSO profile, click its name in the table.
    • To locate an SSO profile, search for it by name; otherwise, look for it on the
      Name
      list.
    • Selecting an SSO profile from the list displays the
      Related Items
      section. Click
      Show
      to display related items such as lease pools, network access, or webtops.
    • To create a new SSO profile, click the
      Create
      button.
    • To delete one or more SSO profiles, select the check box next to each profile and click the
      Delete
      button.
  5. To configure a new SSO profile, click
    Create
    .
    A new SSO profile screen will open.
  6. Type a
    Name
    for this profile. (You cannot change the name of an existing profile.) Avoid using global reserved words such as all, delete, disable, enable, help, list, show, or None.
  7. Enter a
    Partition
    . The default is
    Common
    . You can also enter a custom path to a partition you have created. Only users with access to a partition can view the objects that the partition contains. If the object resides in the
    Common
    partition, all users can access it.
  8. From the
    Scope
    list, select the scope that is applicable for this SSO profile.
  9. If you want to add an SSO configuration, from the
    SSO Configuration
    list, select an existing SSO configuration.
  10. For the
    Log Settings
    , move the log settings you want to use from the
    Available
    list to the
    Active
    list.
  11. To save your changes, click
    Save & Close
    at the bottom of the screen.
The new SSO profile will display in the SSO Profiles list.