Manual Chapter : Single Sign-On

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 7.0.0, 6.1.0, 6.0.1
Manual Chapter

Single Sign-On

About SSO profiles

SAML version 2.0 in BIG-IQ® Centralized Management specifies an SSO profile that involves exchanging information among an identity provider (IdP), a service provider (SP), and a user. The IdP can be any SSO service offering SAML authentication services

What are the supported SSO methods?

BIG-IQ® Centralized Management supports the following 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 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.

Configure an SSO profile

You configure an SSO profile to set up the BIG-IQ system for single sign-on.

  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 the Access group that interests you.
    A new screen displays the group's properties.
  3. On the left, expand SINGLE SIGN-ON and click SSO Profiles.
  4. Click Create.
    The New Profile screen opens.
  5. If you are creating a new SSO Profile, type a Name for it. (You cannot change the name of an existing profile.)
  6. From the Scope list, select the scope that is applicable for this SSO profile.
  7. If you want to add an SSO configuration, from the SSO Configuration list, select an existing SSO configuration.
  8. For the Log Settings, move the log settings you want to use from the Available list to the Active list.
  9. To save your changes, click Save & Close at the bottom of the screen.
The new SSO profile displays in the SSO Profiles 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click NTLMV1.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Settings list, select Advanced.
  6. Type a Name for the SSO configuration.
  7. For Headers, type a header name-value pair to send with the SSO method.
  8. For Log Settings, select the log setting created from event logs.
  9. For Username Source, type the user name you want cached for single sign-on.
  10. For Password Source, type the password you want cached for single sign-on.
  11. To convert the PREWIN2k/UPN user name input format to the format you want to use for SSO, select the Username Conversion check box.
  12. Type the location of the NTLM Domain where all users and groups are authenticated.
  13. 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click NTLMV2.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Settings list, select Advanced.
  6. Type a Name for the SSO configuration.
  7. For Headers, type a header name-value pair to send with the SSO method.
  8. For Log Settings, select the log setting created from event logs.
  9. For Username Source, type the user name you want cached for single sign-on.
  10. For Password Source, type the password you want cached for single sign-on.
  11. To convert the PREWIN2k/UPN user name input format to the format you want to use for SSO, select the Username Conversion check box.
  12. For NTLM Domain, type the location of the domain where all users and groups are authenticated.
  13. 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 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click HTTP Basic.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Properties list, select Advanced.
  6. Type the Name for the SSO configuration.
  7. For Headers, in the Name and Value fields, type a header name-value pair to send with the SSO method.
  8. From the Log Settings list, select the log setting created from event logs.
  9. In Username Source, type the user name source you want to cache for single sign-on.
  10. In Password Source, type the password source you want to cache for single sign-on.
  11. To convert the PREWIN2k/UPN user name input format to the format you want to use for SSO, select the Username Conversion check box.
    For example, convert domain\username or username@domain to username.
  12. To save your changes, click the Save & Close button at the bottom of the screen.
The HTTP basic SSO object displays in the HTTP Basic SSO list.

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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click Form Based.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Settings list, select Advanced.
  6. Type a Name for the SSO configuration.
  7. 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.
  8. In the Name and Value fields for Headers, type a header name-value pair to send with the SSO method.
  9. For Log Settings, select the log setting you want to use.
  10. In the Username Source and Password Source fields, type the user name you want cached for single sign-on.
  11. For Password Source, type the password you want cached for single sign-on.
  12. 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.
  13. 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.
  14. Select the Pass Through check box to propagate cookies present in this form to the client browser.
  15. Select the Form Method you want to use for the form-based HTTP authentication.
  16. 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.
  17. For Form Parameter For User Name, type the parameter name used by the form to which you are sending the POST request.
  18. For Form Parameter For Password, type the parameter name used by the form to which you are sending the POST request.
  19. 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.
  20. For Successful Logon Detection Match Type, select the method your authentication server uses and specify the option definition in the next field.
  21. For Ticket Lifetime, type, in minutes (for example, 600 minutes equates to 10 hours), the lifetime of Kerberos tickets obtained for the user.
  22. To save your changes, click the Save & Close button at the bottom of the screen.
The HTTP form-based SSO object displays 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click Forms - Client Initiated.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. Click GENERAL SETTINGS.
  6. Type an SSO Configuration Name.
  7. Type an optional SSO Configuration Description.
  8. Select the Log Setting you want to use.
  9. Click FORM SETTINGS.
  10. 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.
  11. Type the Form Name and optional Form Description.
  12. 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.
  13. 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.
  14. For Request Method, select whether the request method is GET or POST.
  15. Select the Request Negative check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  16. Select the Request Prefix check box to specify that the system matches on a partial string.
  17. For Identity Form by, select how to find the HTML logon form in the HTML body of the logon page.
  18. For Form Parameters Settings, specify that the form parameters that have already been defined are used to find the form.
  19. For Disable Auto detect submit, the default is No.
  20. The Scheme option is available when Disable Auto detect submit is set to Yes. Select how to detect a submit.
  21. Select the Submit Request Negative check box to specify that the system detects the form that fails to match the criteria specified for form detection.
  22. Select the Submit Request Prefix check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  23. For Detect Login By, select whether and how to detect a successful logon.
  24. For Injection Method, select whether to use the default JavaScript that the system creates.
  25. Click HEADER SETTINGS.
  26. 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 displays in the HTTP FormS-Client Initiated list.

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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click Form Based.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Settings list, select Advanced.
  6. Type a Name for the SSO configuration.
  7. 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.
  8. In the Name and Value fields for Headers, type a header name-value pair to send with the SSO method.
  9. For Log Settings, select the log setting you want to use.
  10. In the Username Source and Password Source fields, type the user name you want cached for single sign-on.
  11. For Password Source, type the password you want cached for single sign-on.
  12. 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.
  13. 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.
  14. Select the Pass Through check box to propagate cookies present in this form to the client browser.
  15. Select the Form Method you want to use for the form-based HTTP authentication.
  16. 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.
  17. For Form Parameter For User Name, type the parameter name used by the form to which you are sending the POST request.
  18. For Form Parameter For Password, type the parameter name used by the form to which you are sending the POST request.
  19. 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.
  20. For Successful Logon Detection Match Type, select the method your authentication server uses and specify the option definition in the next field.
  21. For Ticket Lifetime, type, in minutes (for example, 600 minutes equates to 10 hours), the lifetime of Kerberos tickets obtained for the user.
  22. To save your changes, click the Save & Close button at the bottom of the screen.
The HTTP form-based SSO object displays in the Form Based list.

Create an OAuth bearer SSO configuration

You 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click OAuth Bearer.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. From the General Settings list, select Basic or Advanced.
  6. Type a Name for the SSO configuration.
  7. For Headers, type a header name-value pair to send with the SSO method.
  8. For Log Settings, select the log setting you want to use, created from event logs.
  9. For OAuth Server, select a previously created OAuth server.
The OAuth bearer object displays in the OAuth Bearer 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 the Access group that interests you.
    A new screen displays the group's properties.
  3. Expand SINGLE SIGN-ON and click Forms - Client Initiated.
  4. Click Create.
    The New SSO Configuration screen opens.
  5. Click GENERAL SETTINGS.
  6. Type an SSO Configuration Name.
  7. Type an optional SSO Configuration Description.
  8. Select the Log Setting you want to use.
  9. Click FORM SETTINGS.
  10. 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.
  11. Type the Form Name and optional Form Description.
  12. 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.
  13. 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.
  14. For Request Method, select whether the request method is GET or POST.
  15. Select the Request Negative check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  16. Select the Request Prefix check box to specify that the system matches on a partial string.
  17. For Identity Form by, select how to find the HTML logon form in the HTML body of the logon page.
  18. For Form Parameters Settings, specify that the form parameters that have already been defined are used to find the form.
  19. For Disable Auto detect submit, the default is No.
  20. The Scheme option is available when Disable Auto detect submit is set to Yes. Select how to detect a submit.
  21. Select the Submit Request Negative check box to specify that the system detects the form that fails to match the criteria specified for form detection.
  22. Select the Submit Request Prefix check box to specify that the system detects the form that fails to match the criteria specified for Form Detection.
  23. For Detect Login By, select whether and how to detect a successful logon.
  24. For Injection Method, select whether to use the default JavaScript that the system creates.
  25. Click HEADER SETTINGS.
  26. 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 displays in the HTTP FormS-Client Initiated list.