Manual Chapter : Single Sign-On

Applies To:

  • BIG-IQ Centralized Management

    7.1.0

Updated Date: 07/07/2026

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.

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.

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.

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.

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 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.

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.

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 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-settingfor 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 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.