Allow clients to explicitly choose an authentication method.

Introduction

The Java-Client can access the same censhare system with different authentication methods through different parametrized hosts.xml entries for the same target host.

However, with a browser based client there used to be just a single entry point - a URL like http://localhost.censhare.com:9443/censhare5/client/. In older censhare versions, the required authentication method was determined by looking at cookie values and on the set of authentication method configured at the System Asset. This worked only in specific cases and it was unclear which priority rules were in force.

Whenever the Standard authentication method (hashed password entries in party table) was present, this was selected first. It was impossible to have two (e.g. Kerberos and Standard) authentications running in parallel.

Implementation

The URL contains a "Query Parameter":

• Standard authentication on https://myhost/censhare5/client/ and https://myhost/censhare5/client/?auth=standard • Kerberos authentication on https://myhost/censhare5/client/?auth=kerberos • SAML on https://myhost/censhare5/client/?auth=saml

For ease of use reverse proxy installations may map some URL to the above URLs, e.g. https://customer.com/ to https://int.customer.com/censhare5/client/?auth=saml.

If SAML is active and Standard authentication allowed a successful login with ?auth=standard, this setup will be remembered with the help of a client cookie (CENSHARE_SAML_STANDARD_LOGIN, see SAML-SSO Essentials).

To use Kerberos on Google Chrome requires using the command line below, to launch Chrome:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --auth-server-whitelist="cs-test20171-css01:9443" --auth-negotiate-delegate-whitelist="cs-test20171-css01:9443" --user-data-dir="/tmp/"

Using Kerberos while connected with VPN sometimes requires fiddling around with the command line tools kinit, klist and kdestroy to establish all ticketing requirements. E.g. you must delete all exisiting tickets with kdestry and re-initalize with kinit [your-user-id].

Example session:

/tmp ❯❯❯ kdestroy
/tmp ❯❯❯ klist
klist: krb5_cc_get_principal: No credentials cache file found
/tmp ❯❯❯ kinit ar
ar@INT.CENSHARE.COM's password:
/tmp ❯❯❯ klist
Credentials cache: API:F52FB191-683C-43CD-BC14-5EEFB846BEAD
        Principal: ar@INT.CENSHARE.COM

  Issued                Expires               Principal
Dec  4 08:53:17 2017  Dec  5 08:53:11 2017  krbtgt/INT.CENSHARE.COM@INT.CENSHARE.COM

tgt is the "ticket granting ticket"

After the browser client managed authentication this get visible on the command line as:

/tmp ❯❯❯ klist
Credentials cache: API:F52FB191-683C-43CD-BC14-5EEFB846BEAD
        Principal: ar@INT.CENSHARE.COM

  Issued                Expires               Principal
Dec  4 08:53:17 2017  Dec  5 08:53:11 2017  krbtgt/INT.CENSHARE.COM@INT.CENSHARE.COM
Dec  4 08:55:11 2017  Dec  5 08:53:11 2017  HTTP/cs-test20171-css01@INT.CENSHARE.COM

where cs-test20171-css01 is our test server. Note that this requires careful setup at various places in Active Directory subject to a different documentation.

SSO Logout

Our standard logout page is the login page, which could be counter productive with Single-Sign-On. Therefor, specific logout pages were implemented.

For SAML, this is configurable in app/services/clientdelivery/config.xml in @saml-url2 (see documentation SAML-SSO Essentials).

For Kerberos, this is configurable in app/services/clientdelivery/config.xml in @kerberos-logout-url.

For the logout we use a separate servlet which is by default at https://localhost.censhare.com:9443/logout, and its template is located at app/modules/server/logout-template.ftl. This could be customized for re-login to Kerberos e.g. <a href="${login}/?auth=kerberos">Login again</a>.

Availability

  • 5.8.16
  • 2017.1.7
  • 2017.2.8
  • 2017.3.7
  • 2017.4.4
  • 2017.5.0
  • 2018.1.0