Use Enterprise SSO as the Credential Server for Protected Sites

(1)

Webthority HOW TO

Use Enterprise SSO as the Credential Server

for Protected Sites

This document describes how to integrate Webthority with Enterprise SSO version 8.0.2 or 8.0.3. Webthority can be configured to use Enterprise SSO as a Credentials Server, enabling user credentials such as username and password to be obtained from Enterprise SSO and used to automatically form-fill when a Webthority user attempts to access protected backend content.

The Webthority user must match the Enterprise SSO user, but the Enterprise SSO username for a particular application account can be different.

What the User Sees

1. The user clicks the link to the Webthority proxied content URL.

2. The user is prompted to authenticate with the Webthority Authentication Service.

3. The Content URL is used to look up the credentials to use via the Credentials Server, in this case, Enterprise SSO.

4. The user’s username and password combination is used by Webthority to auto-fill the login form in the Back-End application.

5. The user is automatically logged into the Back-End application.

Server Architecture

For the form-fill via Enterprise SSO credentials functionality, Webthority communicates via web services and so the Webthority and Enterprise SSO installations can be in separate domains. Using LDAP Authentication to Enterprise SSO Domain

The Webthority LDAP Authentication Service can be used to authenticate to the domain managed by Enterprise SSO. In this case, to allow passwords to be changed at the login screen, Webthority needs to use the Enterprise SSO Middleware API. This Middleware must be installed on the same machine as the Webthority Authentication Service, which in turn means that the Webthority host must be a member of the domain managed by Enterprise SSO. To install the Middleware API, the following settings must be selected in the Enterprise SSO Autorun:

1. Configure Workstation

2. Install any of components SSOWatch, Advanced Login or

(2)

Using Enterprise SSO as the Credential Server for Protected Sites

2

Configuration

1 - Enterprise SSO Prerequisite Configuration

This section describes the Enterprise SSO configuration required via the Enterprise SSO Autorun. Installing the Enterprise SSO 8 Server

1. Select Extended Manager mode. 2. Select Using Active Directory.

3. Select Install Web Services components.

2 - Webthority Prerequisite configuration: Back-end Authentication

1. Ensure that the Back-End Auth checkbox is selected on the Proxy Content Server Mapping dialog.

2. On the associated Web role Back-End Auth tab: a. Select the Auto-fill login forms checkbox. b. Add a new row to the form filling table.

c. URL - This is the exact URL for the login form, with the port number explicitly specified (e.g. “https://webmail.quest.com:443/CookieAuth.dll?GetLogon?curl=Z2F&reason=0& formdir=2“

d. The remaining optional fields can be used to assist the form filling algorithm. They specify the:

- name of the HTML login form

- name of the username/password/domain HTML form input fields - format of the username in the form (e.g. <username>@<domain>) e. You can also set a default domain to be used for the form filling if required.

(3)

3

3 - Using HTTPS Protocol to Connect to the Enterprise SSO Server

If you wish to use the test certificate supplied, perform the following steps:

1. Copy the public certificate, server.crt, from the Enterprise SSO Server Apache directory, e.g.: Program Files\Quest\WG WebSrv\Apache2\conf\server.crt

2. In Webthority, use Configure Certificates, Install trusted CA certificate to install

server.crt into the Webthority keystore.

3. Restart the Webthority service.

To use a different Certification Authority on the SSO Server, rename the required Certification Authority’s files to server.crt (certificate, PEM format) and server.key (private key, PEM format), then restart Apache2.

4 - Configuring Webthority Enterprise SSO Communications

On the System Info, SSO tab, complete the form details as described below: 1. Enterprise SSO Server URL. (e.g. https://esso.example.com/soap ) 2. Fully qualified domain of Enterprise SSO.

3. Administrator User for Enterprise SSO Server – enter the user id of the administrator user on the Enterprise SSO Server.

4. Administrator User Password – enter the password of the administrator user. 5. Click Generate New Key Pair. This stores the private key within Webthority.

(4)

4

5 - Importing the External Key into Enterprise SSO

• We recommend that you backup your Enterprise SSO Server before importing an External Key.

• Import the External Key into Enterprise SSO, as described below:

1. Using the Enterprise SSO installation application, select Import an external Key then complete the required information, e.g administrator account details, select PEM file, etc. 2. Configure two policies/profiles in the SSO Console to allow external access (Default profiles are

in “ProgramData\IAM”):

a) On the User Security Profile (e.g.DefaultUserProfile), Security tab check the

Allow External Access checkbox.

b) On the Application Security Profile (e.g. DefaultApplicationProfile), Account tab, under Encrypt by, drop down menu select Users, Administrators and

External Key.

c) Ensure that these two profiles are used by users and the applications needed by Webthority.

3. Restart the Quest E-SSO Security Services and Apache2 (SOAP interface) Windows services (or restart the Server).

4. Each user (owner of account information) must then logon to a rebooted machine with a cleared cache (with default ESSO cache settings. One way to ensure this is to wait 24hrs after performing steps 1-3, then reboot the workstations, and then ask the user to logon. The ESSO cache files can also be cleared manually on the workstation by deleting the contents of

C:\Program Files\Common Files\Evidian\WGSS\CacheDir).

Webthority should be able to access and decrypt the SSO credentials of this user.

To check that ESSO has been configured correctly to allow credentials to be sent over the API and decrypted by Webthority, a tool is provided in the bin directory: SSOCheck. Run it from a

command prompt without arguments to see a set of usage instructions. For further information, refer to the Enterprise SSO documentation.

6 - Configuring Enterprise SSO Application Names Mapping

To enable the form filling mechanism to use the credentials correctly, add the required entries to the SSO Mappings table on the SSO tab for the relevant Web Role.

The Application is the Enterprise SSO Application name of the credentials to use.

(5)

5 The following example shows what the Url would be for a login page with the URL:

https://login.mydomain.com/config/mail?.intl=uk&.src=ym The URL used in this map could be any of the following examples:

https://login. mydomain.com/ https://login. mydomain.com/config/ https://login. mydomain.com/config/mail/ The last example is the best as it is the most specific.

Known issues

Pre-existing account passwords

Pre-existing E-SSO accounts are not re-encrypted with an external key immediately the application profile is changed. This means that Webthority will not be able to decrypt the account password.

Multiple External Keys

Enterprise SSO will apply the first imported external key to any existing Enterprise SSO users and any new users subsequently added. We recommend that a single external key only is generated by Webthority and imported into Enterprise SSO.

If subsequent keys are generated using Webthority and imported into Enterprise SSO, they will be used by Enterprise SSO only when the Enterprise SSO service is:

• deleted or expired (default – 5 minutes) • restarted.

Webthority maintains a list of all generated keys and will try them in reverse time order (latest first etc). Generating a large number of keys in Webthority can significantly slow this process and is, therefore, not recommended.

Troubleshooting

To assist with problems with E-SSO credentials playback enable debug logging on the Proxy and search for the E-SSO debug printouts (all start with “ESSO:”).