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