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.
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
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
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
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
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
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
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
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