Defining a Single Sign-On Autopolicy

Single sign-on policies enable you to automatically pass user credentials to the Web application specified in your policy. Single sign-on autopolicies also intermediate the data that you pass.

To create a single sign-on (SSO) autopolicy:

1.Create a Web resource profile.

2.If available, click the Show ALL autopolicy types button to display the autopolicy configuration options.

3.Select the Autopolicy: Single Sign-On check box.

4.Select a single sign-on method and configure the corresponding SSO options:

SSO options require you to select credentials. If you have not already done so, define the credentials using the Resource Policies > Web > General page prior to defining your SSO autopolicy.

•Disable SSO - Disables single sign-on.

•Basic Auth - Enables the system to intermediate the challenge/response sequence during basic authentication and use the credentials it collects to sign into a protected resource within the same Intranet zone. This option does not apply to Citrix resource profiles.

•NTLM - Enables the system to intermediate the challenge/response sequence during NTLM authentication and use the credentials it collects to sign into a protected resource within the same Intranet zone. This option does not apply to Citrix resource profiles.

Web rewriting and file browsing both support NTLM v1 and NTLM v2.

•Kerberos - Enables the system to intermediate the challenge/response sequence during Kerberos authentication and use the credentials it collects to sign into a protected resource within the same Intranet zone.

•Constrained Delegation - Enables authentication of users by Kerberos after their identity has been verified using a non-Kerberos authentication method. For example, suppose a user authenticates with RADIUS and enters their passcode (typically PIN and tokencode). When accessing a service, the user may be challenged again because the PIN is not recognized. With constrained delegation, the administrator sets up passwords for constrained delegation users. The users do not need to know this password. When accessing the same HTTP service, the system now fetches the ticket on behalf of the user without challenging the user.

•Remote SSO - Enables the system to post the data that you specify (including usernames, passwords, and system data stored by variables) to Web applications. This option also enables you specify custom headers and cookies to post to Web applications.

5.Click Save Changes.

Specifying Basic Authentication, NTLM or Kerberos SSO Autopolicy Options

To configure basic authentication, NTLM or Kerberos SSO autopolicy options:

1.Create an SSO autopolicy and choose Basic Auth, NTLM or Kerberos.

2.In the Resource field, specify the resources to which this policy applies.

When entering a resource in this field, note that:

•If you want to automatically post values to a specific URL when an end-user clicks on a system bookmark, the resource that you enter here must exactly match the URL that you specify in the Base URL field of the resource profile.

•If you want to automatically submit user credentials to other web sites within the same Intranet zone, the hostname that you enter here must end in the DNS suffix configured in the System > Network > Overview page of the admin console.

3.Select the credentials to use. If this pull-down menu is blank, no credentials are defined in the SSO General tab.

4.(NTLM only) Select the Fallback to NTLM V1 option to fallback to NTLM V1 if NTLM V2 fails. If you do not select this option, the system falls back only to NTLM V2. An intermediation page appears if SSO fails.

5.(Kerberos only) Select the Fallback to NTLM V2 only option to fallback only to NTLM V2 if kerberos fails. If you do not select this option, a Kerberos intermediation page appears if Kerberos SSO fails.

6.(Constrained delegation only) Select the Fallback to Kerberos option fallback to Kerberos if constrained delegation fails. If you do not select this option, an error page appears if SSO fails.

Specifying Remote SSO Autopolicy Options

To configure remote SSO autopolicy options:

1.Create an SSO autopolicy through a custom Web resource profile and choose Remote SSO.

2.If you want to perform a form POST when a user makes a request to the resource specified in the Resource field, select the POST the following data check box. Then:

•In the Resource field, specify the application's sign-in page, such as: http://my.domain.com/public/login.cgi. Widlcard characters are not supported in this field.

If you want to automatically post values to a specific URL when an end user clicks on a system bookmark, the resource that you enter here must exactly match the URL that you specify in the Base URL or Web Interface (NFuse) URL field of the resource profile.

•In the Post URL field, specify the absolute URL where the application posts the user's credentials, such as: http://yourcompany.com/login.cgi. You can determine the appropriate URL using a TCP dump or by viewing the application's sign-in page source and searching for the POST parameter in the FORM tag.

•Optionally specify the user data you want to post and user modification permissions.

•To specify user data to post, enter data in the following fields and click Add:

•Name - The name to identify the data of the Value field. (The back-end application should expect this name.)

•Value - The value to post to the form for the specified Name. You can enter static data, a system variable, or system session variables containing username and password values.

•User modifiable? setting - Set to Not modifiable if you do not want the user to be able to change the information in the Value field. Set to User CAN change value if you want the user to have the option of specifying data for a back-end application. Set to User MUST change value if users must enter additional data in order to access a back-end application. If you choose either of the latter settings, a field for data entry appears on the user's Advanced Preferences page. This field is labeled using the data you enter in the User label field. If you enter a value in the Value field, this data appears in the field but is editable.

•Select the Deny direct login for this resource check box if you do not want to allow users to manually enter their credentials in a sign-in page. (Users may see a sign-in page if the form POST fails.)

•Select the Allow multiple POSTs to this resource check box if you want to send POST and cookie values to the resource multiple times if required. If you do not select this option, the system does not attempt single sign-on when a user requests the same resource more than once during the same session.

3.If you want to post header data to the specified URL when a user makes a request to a resource specified in the Resource field, select the Send the following data as request headers check box. Then:

•In the Resource section, specify the resources to which this policy applies.

•Optionally specify the header data to post by entering data in the following fields and clicking Add:

•Header name - The text to send as header data.

•Value - The value for the specified header.

4.Click Save Changes.