Single Sign On

Single Sign On (SSO) eliminates the need for users to reauthenticate to an application when they access it for a second time, during a Mobile Access session, or between sessions. The authentication credentials used to log in to the Mobile Access portal can be re-used automatically to authenticate to multiple applications accessed through Mobile Access. You can also record other credentials for the application, and store them for future use. SSO user credentials are securely stored on Mobile Access and therefore remain valid even if the user logs in from a different client machine.

Supported SSO Authentication Protocol

Mobile Access supports Single Sign On for authentication to internal Web and other application servers. The supported authentication protocols are:

• Basic Access - RFC enhancement. Not recommended because of security implications.
• Digest Access - RFC enhancement.
• Integrated Windows Authentication - RFC enhancement. Formerly NTLM version 1.
• Credential forwarding in HTTP headers - Ad hoc solution. Not recommended because of security implications.
• Web form (HTML) based.

HTTP Based SSO

For applications that perform authentication at the HTTP level, HTTP-based SSO is available, in which the credentials are forwarded in HTTP headers. This applies to the Basic, Digest, Integrated Windows Authentication, and Credential forwarding in HTTP headers authentication protocols.

When the user attempts to access these sites, a browser-specific form appears:

The user must enter his/her user name and password for that application, and click OK.

HTTP Based SSO Limitation

If the Web server requests authentication for a POST request in either the digest or Integrated Windows Authentication methods, and the server does not support sending of "100 Continue" responses, Single Sign On is not supported.

Web Form Based SSO

Most Web applications have their own Web forms for authentication. For these applications, Mobile Access supports Web form (HTML) based SSO.

The advantage of Web form based SSO authentication over HTTP authentication is that users are presented with the login page of the application itself, rather than a more obtrusive browser-specific page.

A typical Web form is shown below, for Outlook Web Access, together with a Mobile Access SSO popup that assists the user.

It is recommended to use the Web form based SSO for every application that is configured to work with Web form authentication. Do not enable Web form SSO for other applications, in order to maintain performance and connectivity.

Application Requirements for Easy Configuration

Web form based SSO in its default configuration can be configured by selecting a single check box in SmartDashboard. In order for the default settings to work, the application must:

• Present the login form as the first form seen by the user.
• Redirect (status 301 or 302) on login success.

Web Form Based SSO Limitations

Web form based SSO does not support:

• Password remediation forms.
• Forms containing 'old/new/confirm' password fields. These fields are not recognized properly, and wrong credentials may be recorded or forwarded.

Application and Client Support for SSO

The following table shows which SSO methods are available for each Mobile Access application:

Most Mobile Access Web Applications and Citrix Services support Web Form SSO, with either no configuration, or minimal configuration required. Some applications have been tested and found to require manual configuration (of the HTTP Post details). Some applications do not support Web Form SSO at all.

For a list of common applications that are certified by Check Point to work with Web Form SSO, see SecureKnowledge solution sk35080.

Mobile Access Client Support for SSO

Single Sign On is available only via the Mobile Access portal. It is not available for authentication via the VPN clients: SSL Network Extender, SecureClient Mobile, and Endpoint Connect.

Basic SSO Configuration

To configure a basic SSO setup:

1. In the SmartDashboard Connectra tab, select the Additional Settings > Single Sign On page.
2. In the Single Sign On page, select an application and click Edit.

   The Single Sign On page of the application window opens.

3. Select Turn on single Sign On for this application.
4. Configure the sign on method for the application. The default option is:

   For Web applications, File Shares and Citrix Services:
   Prompt the users for their credentials and store them for future use

   For Web Mail applications this same option is called:
   Prompt user for credentials

   With this option, the application credentials are stored and reused. The portal credentials are not used to authenticate to applications.

Basic Configuration of Web Form SSO

Web form SSO is supported only for Mobile Access Web applications and Citrix services.

In the default settings, Web Form Single Sign On automatically analyses the sign-in Web page of the application. The default settings assume:

• HTTP redirect (301, 302) upon authentication success.
• No redirect upon authentication failure.

To configure Web Form SSO with default settings:

In the Single Sign On page of the Connectra application, select This application uses a Web form to accept credentials from other users

Advanced Configuration of SSO

The following configuration instructions apply to both HTTP based SSO and to Web form based SSO. The advanced configuration options are supported for Web applications, file shares, and Citrix services.

For configuration options that are specific to Web form SSO, see Advanced Configuration of Web Form SSO.

Configuring Advanced Single Sign On

There are a number of Single Sign On methods. The different options allow you to configure how to handle portal credentials, and how to handle other credentials used to authenticate to the application.

To configure the Single Sign On methods:

1. Go to the Single Sign On page of the Mobile Access application.
2. For the Advanced options, click Edit.

These are the available single sign on methods.

Configuring Login Settings

Login settings allow you to configure the default Windows domain (if Windows authentication is being used), to notify users that their credentials will be stored, and to specify a hint to help users supply the correct credentials.

To configure the login settings for Single Sign On:

1. Go the Single Sign On page of the Mobile Access application.
2. In the Login Settings section, click Edit.

   The Login Settings window opens.

3. Fill in the fields according to the explanations below.

Windows Domain

• The user of this application belongs to the following Windows domain:

  Specify the Windows domain or workgroup (for example "LOCALDOMAIN") if Windows authentication is used. Integrated Windows authentication requires the domain to be forwarded with the user name and password.

  If Accept the portal credentials from the gateway Single Sign On method is used, Mobile Access does not know the domain, because the user does not supply it with the portal credentials. The domain is fetched from the one specified here.

User Notification

• Notify the users that their credentials for this application are going to be stored

  When users access the application login page for the first time, they see a message that their credentials will be stored for future access.

• Allow the users to specify that their credentials for this application will not be stored

  When users access the application login page for the first time, they see a message from which they can select not to record their credentials.

Administrator Message

• Show the following message together with the credentials prompt

  Show a hint to the user about the credentials they must supply. for example, whether or not they should supply the domain name and user name (for example: AD/user) or just the user name (for example: user). After clicking the Help me choose credentials link, the user sees the hint. The message can include ASCII characters only.

Advanced Configuration of Web Form SSO

Use the advanced Single Sign On settings for Web form credentials to configure an application for Web form SSO if there is one of these:

• No HTTP redirect (301, 302) upon authentication success
• No redirect upon authentication failure.

You can specify different criteria for:

• Sign In Success or Failure Detection
• Credential Handling

Sign In Success or Failure Detection

Most Web applications respond to authentication success by redirecting to another page. If a redirect is not an indication of success, you can configure a different indicator of success or failure.

To configure Sign In success or failure criteria:

1. In the Single Sign On page of the Mobile Access application, in the Web Form section, click Edit.
2. Select Specify a criterion for success or failure and then select one of the following options:
   • Mobile Access regards the authentication as successful, if after signing in, this application creates a cookie with the following name:
     The application places a session cookie upon success. To obtain the exact name of the session cookie, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy)
   • Mobile Access regards the authentication as a failure, if after signing in, this application redirects to the following URL:
     The application redirects on failure. To find the target URL, install a sniffer or browser plug-in (such as the Fiddler HTTP debugging proxy). Use the following URL format:
     <protocol>://<host>/[<path>][?< query>]

Credential Handling

By default, Mobile Access looks for the user name and password fields at the application URL. If the default settings do not work, you can either configure an automatic credential detection method, or you can manually hard-code the POST details.

To configure automatic credential handling:

1. In the Single Sign On page of the Mobile Access application, in the Web Form section, click Edit.
2. In the Credentials Handling section, click Edit.

   The Credentials Handling window opens.

3. Select Automatically handle the credentials.
4. Under Sign in Web Form Detection Settings, select:

   Mobile Access regards the following URL as the sign in Web form:

   If the application presents a Web form that requires credentials, before the actual login form, so that Mobile Access is unable to automatically analyze the sign-in Web page, you can specify the URL of the actual login form.

   Syntax:
   <protocol>://<host>/[<path>][?< query>]

5. Under Password Validation Settings, select

   Mobile Access sends the following password:
   Clients need to submit the sign on Web form with a user name and password. However, it is not secure to store the password on the client for future SSO use. Mobile Access therefore generates a dummy password that it sends to the client, and replaces it upon sign on with the real password. Some applications check the dummy password on the client side. If the Mobile Access dummy password is not compatible with the application, you can define a different one.

Manually Defining HTTP Post Details

If automatic Web form SSO does not work, you can define HTTP POST details.

To manually specify how to handle credentials:

1. From the Credentials Handling window, select Manually specify how to handle the credentials.
2. Fill in the fields for When the following sign in URL is requested:
   • post to the following URL
     In this and the previous field, the URL must be absolute. Use the URL format
     <protocol>://<host>/[<path>][?< query>]
   • the following POST data, which must include:
     • $USER NAME resolves to the user name stored on Mobile Access.
     • $PASSWORD resolves to the password stored on Mobile Access.

When manual credential handling is configured for Web form SSO, the HTTP authentication request window appears, when credentials are requested for the first time.

Kerberos Authentication Support

Kerberos is a network authentication protocol, which allows people and computers to securely identify themselves over a non-secure network. It is the Microsoft default authentication protocol in Windows 2000 and later versions. Microsoft IIS, and other web servers, can use Kerberos via the Negotiate method in HTTP authentication headers.

Kerberos Authentication is supported for Web Applications (HTTP(S)). Mobile Access can authorize against Kerberos servers on behalf of users.

By default, Kerberos support is turned off.

To turn on support for Kerberos:

1. Replace /etc/krb5.conf with a file suitable for the domain. The file must have the following template. Replace any string containing “your” with the appropriate values:

   [libdefaults] default_realm = YOUR.AD.NAME [realms] YOUR.AD.NAME = { admin_server = your.domain.controller.name default_domain = your.dns.domain } [domain_realm] .your.dns.domain = YOUR.AD.NAME your.dns.domain = YOUR.AD.NAME

   • YOUR.AD.NAME is the Windows domain name.
   • To configure more than one Windows domain (also known as a “Realm”), add more domains to the [realms] section and to [domain_realm] section.
   • For each realm you can have more than one domain controller, in this case, instead of the admin_server statement, use several statements of the form:
2. Make sure clocks on the Mobile Access gateway and on the domain controller(s) are synchronized to within 1 minute. The best way to ensure this is to use an NTP time server.
3. Check that Kerberos is configured correctly.
   1. From the Mobile Access gateway command line, type:

      kinit your-ad-username

      If there are several realms, the kinit syntax works for the default realm. For other realms, use the syntax: kinit your-ad-username@YOUR.OTHER.AD.NAME

      You should get a prompt, similar to: Password for your-ad-username@YOUR.DOMAIN:

   2. Type the password and press Enter.

      There should be no error messages

   3. Type klist

      You should get a listing of something called "Ticket cache", with one ticket in it.

   4. You must delete the list. To do so, type kdestroy
4. Use the cvpnd_settings command to enable Kerberos:

   cvpnd_settings set useKerberos true cvpnd_settings listAdd kerberosRealms YOUR.AD.NAME cvpnd_settings listAdd kerberosRealms YOUR.OTHER.AD.NAME

5. Restart the Mobile Access services by running cvpnrestart.
6. For a cluster setup, repeat step 1 to step 5 on each cluster member.