Webthority HOW TO Configure Web Single Sign-On

Webthority HOW TO
Configure Web Single Sign-On
Webthority can provide single sign-on to web applications using one of the following authentication
methods:
•
•
•
HTTP authentication (for example Kerberos, NTLM, Digest or Basic)
Form based authentication
SAML IDP
HTTP Authentication
HTTP authentication is the most common authentication method used on internal web applications.
Applications running on IIS, for example, will often use Integrated Windows Authentication which
consists of both NTLM and Kerberos HTTP authentication. This method of authentication is typically
transparent to the user and performed automatically by the browser using the user’s Active Directory
credentials.
Currently Webthority supports the following HTTP authentication methods:
•
•
•
•
Kerberos
NTLM
Digest
Basic
To configure HTTP authentication:
1) Login to the Admin Console and select the proxy service that protects the application you want
to configure for SSO.
2) Select the Content Server Mappings tab and check the Auto Back-End Auth box for the
application’s content mapping(s).
3) Select the Web Role that protects the application, then select the Back-End Auth tab.
4) Check the appropriate authentication box and enter the domain name (fully qualified or netbios)
where the application resides. For Kerberos back-end authentication refer to the “Additional
Configuration for Kerberos HTTP Authentication” for additional configuration steps.
Webthority How To Configure Web Single Sign-On
Form-based Authentication
Some applications, especially those that are Internet facing, choose to use form-based authentication.
This means they display username and password fields on the webpage for the user to manually enter
their sign-in credentials.
To configure form-based authentication:
1) Login to the Administration Console and select the proxy service that protects the application
you want to configure for SSO.
2) Select the Content Server Mappings tab and check the Auto Back-End Auth box for the
application’s content mapping(s).
3) Select the Web Role that protects the application, then select the Form Templates tab.
4) Click Add New, then enter a name to identify the login form. This name is used internally by
Webthority and should be made up of alphanumerics and underscore characters only.
5) Next, enter the Trigger URL for the application. The Trigger URL is the URL of the application’s
login page. The URL can be obtained by accessing the application directly and navigating to its
login page. When the login page is displayed, copy the URL from the address bar in the browser
and paste it into the Trigger URL field. If the application uses frames so that several Web pages
can be displayed in the same browser window you will need to obtain the URL of the page
containing the login form and not the URL of the frame set.
The Trigger URL should also include, if given, any query string included in the URL, for
example:
&name1=val1&name2=val2
The name value pairs in the query string may have their values individually replaced with
wildcards using the three character sequence <*>. For example:
&name1=<*>&name2=val2
6) If the application uses the same credentials that the user will use to authenticate to Webthority,
for example their Active Directory account, select Primary Webthority Sign In to pass through
the credentials.
Alternatively, if the application uses its own credentials, choose Webthority Datastore to allow
Webthority to capture and store the credentials during the user’s first authentication. The next
time the user uses Webthority, the captured credentials will be used to single sign-on (SSO) to
the application. If the stored password is no longer valid, for example if the user was to change
their password, Webthority will fail to automatically SSO into the application the next time they
access it causing the application to prompt for the users credentials. Webthority will
automatically capture the new credentials and replace the old stored credentials with the new
credentials.
The default behavior of Webthority is to populate the login form with the user’s credentials,
leaving the user to manually click the Log in button.
Webthority can also automatically click the Log in button for the user. To enable this behavior,
continue with the steps below to configure auto submit.
7) Check the Auto-Submit box.
2
Webthority How To Configure Web Single Sign-On
8) Next, select when you want Webthority to Automatically Submit the login page.
Select Once per session (the default) to submit the login form once during a user’s Webthority
session. If Webthority has already submitted the form during the user's current session,
Webthority will populate the login form with the user's credentials, but the form will not be
automatically submitted a second time.
Select Always to enable Webthority to automatically submit the login form every time.
Care should be taken when using this option for applications which return the user to the
login page in situations where you would not want another SSO attempt. For example when a
user clicks the application’s logoff button or when a user is denied access to an area of the
application. Before enabling this option for applications which return the user to the login page,
first ensure that the URL of these login pages is different to the URL defined as the login Trigger
URL to avoid unwanted SSO attempts.
9) Next, select how you want Webthority to fill in the login form.
Client-side:
The login form is populated in the user’s web browser and the Log in button is automatically
clicked. This is the default method, and is required if a form uses JavaScript.
You may need to enter the HTML ID of the Log in button if Webthority is unable to automatically
detect the button (for example, if the credentials are populated, but the button is not clicked).
The ID can be obtained by viewing the source of the HTML page containing the login form
and locating the id attribute of the Log in button.
Server-side:
The login form is intercepted by the Webthority proxy and automatically processed,
transparently to the user.
Webthority can also populate password change forms with the user’s current password. This provides a
more complete SSO solution as the user does not need to recall the current password for an application
when a password change is required.
To configure a password change form:
1) Click the + button located next to the Login Form tab.
2) Enter the Trigger URL for the application in the Trigger URL field.
The Trigger URL is the URL of the application’s change password page. The URL can be obtained
by accessing the application directly and navigating to its change password page. When the
change password page is displayed, copy the URL from the address bar in the browser and paste
it into the Trigger URL field. If the application uses frames so that several Web pages can be
displayed in the same browser window you will need to obtain the URL of the page containing
the change password form and not the URL of the frame set.
3) Next complete the Form HTML field, the default setting is <auto-detect> if Webthority is
unable to automatically detect the form you can manually enter the HTML ID.
The HTML ID can be obtained by viewing the source of the HTML page containing the change
password form and locating the id attribute of the form.
3
Webthority How To Configure Web Single Sign-On
4) Then complete the Old Password Field HTML, the default setting of <auto-detect> will be
applied. If Webthority is unable to automatically detect the field you can manually enter the
HTML ID of the old password field.
SAML IDP
Security Assertion Markup Language (SAML) is a popular open standard for performing Web Browser
Single Sign-On (SSO) to applications outside of the local intranet, for example, to cloud based
applications such as Salesforce and GoogleApps. Typically, a SAML aware application called a Service
Provider (SAML SP) will redirect users to a separate authentication server called an Identity Provider
(SAML IDP) deployed within their organization when they need to authenticate.
If a SAML IDP is already present, Webthority can SSO to the IDP using one of the above HTTP or formbased authentication methods. The IDP will then SSO back to the application. Alternatively, the built-in
SAML IDP supplied with Webthority can be configured to handle the authentication requests from the
web application directly.
To configure the built-in SAML IDP to allow SAML aware applications to authenticate directly, you will
need to perform the following steps:
The IDP Service component must be installed. It is installed by default when using either the Quest
One or Profile installation type.
1) Create a Proxy Mapping for the IDP
The built in SAML IDP component is installed on the same host as the Webthority Administration
Service and can be thought of as just another content server. In the same way that you would
add a proxy content mapping to make an internal content server accessible over the internet
you need to add a content mapping to make the built-in IDP accessible to external users.
Add the following content mapping:
•
Proxy URL:
https://<proxy public hostname>:443/IDP
•
Content Server URL:
https://<Webthority admin host>:8553/IDP
The checkboxes for the mapping can be left unchecked.
4
Webthority How To Configure Web Single Sign-On
2) Create a Web Role for the IDP
Before the IDP can be accessed by external users you need to create a web role to protect the
IDP proxy mapping. Create a new web role and protect it with the required Webthority
Authentication Service, for example the LDAP Authentication Service. On the Groups tab select
a group that will include all users. On the Protected Content tab, assign the IDP proxy
mapping created above to its list of protected content.
Authorization will be controlled by the IDP on a per application basis. Users require a SAML
Subject mapping for the application within the datastore before they can be authorized.
3) Create a Uniquely Identifying URL for the IDP
(Also known as the SAML Issuer or Entity ID).
From the Administration Console, click the IDP node in the navigation pane and select the
General tab. Enter the Proxy URL from Step 1 into the SAML Issuer field. For example:
https://<proxy public hostname>:443/IDP.
4) Add the Application’s SAML Details to the Webthority IDP
From the Administration Console, click the IDP node in the navigation pane and select the SP
Config tab.
Click Add New to add a new SAML Service Provider and enter an identifier for the application.
This name is only used internally by Webthority. You can choose any alphanumeric name, for
example SalesForce or GoogleApps.
a)
Enter the SAML Recipient URL for the application. For example:
https://www.google.com/a/mygoogleappsdomain.com/acs
The application may also refer to this as the Assertion Consumer Service.
b)
Enter the SAML Audience URL for the application. For example:
https://www.google.com/a/mygoogleappsdomain.com
The application may also refer to this as its Entity ID.
c)
(Optional) Enter the SAML Default relay state URL for the application. If this field is
blank, users are sent to the default page for the application. If an alternative page is
required, enter the full URL for the required page. For example:
https://mail.google.com
d)
Click New Key Pair, then click Save Key Pair to save the generated certificate to disk.
5
Webthority How To Configure Web Single Sign-On
5) Add the Application’s Users to the Datastore
Before Webthority users can access SAML aware applications you need to map each Webthority
user to their userid for the SAML application, known as a SAML Subject.
From the Administration Console, click the Datastore node in the navigation pane and select
the SAML Subjects tab. Users can be imported from a .CSV file for convenience, but for now
we will add just a single user in order to test the configuration. Click Add, then enter the
following information:
•
Webthority User
The Webthority user is the userid known to the Webthority Authentication
Service that protects the IDP. For example if the LDAP Authentication Service is
being used then the Webthority user will be the user’s LDAP DN, for example
CN=John Doe,CN=Users,DC=somecompany,DC=com.
•
SPID
The SPID is the SP Identifier that was chosen for the SAML aware application in
Step 4.
•
SAML Subject
The Subject is the userid given to the user by the SAML aware application.
6) (Optional) Add a Button for the SAML SP to the Landing Page
This step is only required if you want a button for the application displayed
on the user’s Webthority Landing Page.
a) Create a new web role and protect it with the same Webthority Authentication Service
that protects the IDP, for example the LDAP Authentication Service.
On the Groups tab, select the groups you want to have access to the application. On the
Protected Content tab, assign the IDP proxy mapping created above to its list of
protected content and enter a slash followed by the SP Identifier chosen in Step 4, in the
URL extension field, for example:
https://<proxy public hostname>:443/IDP/<SP Identifier>
b)
Now add a new Landing Page button. From the Administration Console, click the
Landing node in the navigation pane and select the Menu tab. Click Add and configure
the new button. The Target URL must be the same URL used in the above step, i.e. the
IDP proxy mapping appended with the SP Identifier.
6
Webthority How To Configure Web Single Sign-On
7) Configure the Application with the Webthority IDP Details
This step will vary depending on the application but generally involves providing the application
with the following IDP information:
•
•
Certificate:
A copy of the certificate saved in step 4.
Login URL:
https://<proxy public hostname>:443/IDP/SPInit/Login
Depending on the application, you may also need to complete the following fields:
•
•
Entity ID/Issuer:
https://<proxy public hostname>:443/IDP
Logout URL:
https://<proxy public hostname>:443/IDP/SPInit/Logout
•
Change pwd URL:
https://<proxy public hostname>:443/IDP/SPInit/ChangePwd
Additional Configuration for Kerberos HTTP Authentication
Three modes of Kerberos HTTP Authentication (SPNEGO) are supported in Webthority to allow backend
SSO to content server hosts requiring Kerberos authentication. These three modes are described below.
Use delegation (VSJ Kerberos only)
This mode is exclusively for use with the VSJ Authentication Service and will allow users to access
content server hosts requiring Kerberos authentication via unconstrained delegation. To configure this
mode:
1) In Active Directory Users & Computers, view the Properties for the VSJ service account
user created for the VSJ Authentication Service.
2) On the Delegation tab select Trust this user for delegation to any service (Kerberos
only). If you are using Windows 2000 you will need to select the Account is trusted for
delegation on the Account tab instead.
3) In the Webthority Admin Console select the Web Role that protects the application, then
select the Back-End Auth tab.
4) Select the Use delegation (VSJ Kerberos only) option in the Kerberos Credentials section
and click Apply.
7
Webthority How To Configure Web Single Sign-On
Generate from AD password
This mode is for use with the LDAP Authentication Service (when configured to authenticate to Active
Directory) and will allow users to access content server hosts requiring Kerberos authentication by using
the username and password the user entered during their Webthority authentication. To configure this
mode:
1) In the Webthority Admin Console select the Web Role that protects the application, then
select the Back-End Auth tab.
2) Select the Generate from AD password option in the Kerberos Credentials section and click
Apply.
Generate using Service account
This mode is for use with Authentication Services where only the users Active Directory username is
available and will allow users to access content server hosts requiring Kerberos authentication via
constrained delegation. For example this option would be used when using the Defender Authentication
Service configured with a username and token policy. This mode requires the following additional
configuration:
1) In Active Directory Users & Computers, create a new domain user called, for example, “vsjservice” with the password set to never expire. This service account will be used by Webthority
to perform the constrained delegation.
2) If the domain is at the Windows Server 2008 domain functional level, select the AES 128 bit
and AES 256 bit encryption options on the Account tab for the new service account.
3) From a command prompt assign the service account an SPN to enable delegation. For example:
# setspn -A HTTP/webapps.democorp.com vsj-service
Where “webapps.democorp.com” is the Public host name of the proxy protecting the content
server requiring Kerberos authentication and “vsj-service” is the name of the service account
created above.
The SPN assigned to the service account does not actually need to be the Public host name of
the proxy and can be anything you like. However for compatibility with the VSJ Authentication
Service we recommend setting it to be the Public host name so that a single service account
can be used for both front and back end Kerberos authentication if required.
4) In Active Directory Users & Computers, view the Properties for the service account and
select the Delegation tab.
5) Select Trust this user for delegation to specified services.
6) Select Use any authentication protocol.
7) Click Add and enter the hostname of each content server host requiring Kerberos authentication
and select the HTTP service for each host.
8
Webthority How To Configure Web Single Sign-On
8) In the Webthority Admin Console select the Web Role that protects the application, then
select the Back-End Auth tab.
9) Select the Generate using Service account option in the Kerberos Credentials section and
enter the details of the service account created above then click Apply.
If the content server host is using an alias you will need to enter its Active Directory computer
name in the Content Server Computer Name field.
To troubleshoot Kerberos authentication edit the file “<WEBTHORITY_HOME>\classes\log4j.xml” on the
proxy hosts and change the priority values for the log file appenders to DEBUG. Additional Kerberos log
messages will then be written to “<WEBTHORITY_HOME>\logs\vsj.log” and
“<WEBTHORITY_HOME>\logs\questwth.log”.
<category name="com.dstc">
<priority value="DEBUG"/>
<appender-ref ref="VSJ"/>
</category>
<category name="com.wedgetail">
<priority value="DEBUG"/>
<appender-ref ref="VSJ"/>
</category>
<category name="com.quest.webthority ">
<priority value="DEBUG"/>
<appender-ref ref="QWTH"/>
</category>
If you are having problems with the Webthority proxy hosts communicating with DNS or AD hosts then
the configuration file “<WEBTHORITY_HOME>\classes\wth-kerbcfg.properties” can be used to point
Webthority at a specific set of hosts for Kerberos authentication. Typically the firewall between the DMZ
where the proxy hosts are deployed and the Intranet where the AD hosts reside will need to be updated
to allow the proxy hosts to communicate to the AD hosts via DNS (UDP 53 and TCP 53), Kerberos (TCP
88) and LDAP (TCP 389).
© 2012 Quest Software, Inc. ALL RIGHTS RESERVED.
Quest, Quest Software and the Quest Software logo are trademarks and registered trademarks of Quest Software,
Inc. in the United States of America and other countries. Other trademarks and registered trademarks are property
of their respective owners.
9