This article gives an overview of configurable authentication methods that can be applied to censhare Web.

All methods are available in the System asset as shown in the image below:

The configuration found in the System asset is used for dispatching to an authentication method in:

    HttpServlet.service()->DeliveryServlet.doGet()->AuthenticationManager.handleRequest()->invalidAuth()

Note: Some authentication methods are chosen implicitly, while some must be selected by a query parameter in the URL.

Standard

The Standard authentication method, checks the authentication against the hashed password entry in the database party.password table.

The client login entry point is handled by SessionCommandHandlers and the modules/server/login-standard.xml configuration.

Custom (LDAP)

LDAP can be selected in the System asset by choosing the "Custom" authentication method option. When "Custom" is set, a hard-coded algorithm is used, which is described below:

The LDAP authentication method will be triggered when a censhare Web login has no party entry in the database (i.e. is not a user yet). For already existing party users, LDAP will be triggered first and if unsuccessful the login automatically falls back to "Standard".

The client login authentication is handled by SessionCommandHandlers and the modules/server/login-custom.xml configuration. The login-custom.xml configuration, is heavily customized depending on the actual installation to map user attributes into censhare domains, groups and roles.

Finally, LDAP can be used with the query parameter ?auth=standard in the URL, if the users have the external authentication enabled.

Notes:

  1. The release code in app/modules/ldap/* and app/modules/server/LoginCustom.java will not work out of the box. Further configuration of LDAP mappings is subject to custom setup done by the censhare Professional Services department.
  2. The combination with Kerberos-SSO hasn't been tested yet.

Kerberos-SSO

This authentication method can be selected in the System asset by choosing the "Kerberos" authentication method option. Its configuration is handled by app/config/jaas.conf and can be explicitly used by a query parameter in the URL ?auth=kerberos.

This implementation uses web browser SPNEGO without NTLM fallback. Therefore, the quality of the implementation and the configuration must be checked for each used browser. For example, at the moment in Google Chrome the command line must declare the target host as shown below:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --auth-server-whitelist="cs-test20175-css01:9443" \
  --auth-negotiate-delegate-whitelist="cs-test20175-css01:9443" \
  --user-data-dir="/Users/foo/chrome-kerberos-user-dir"

Notes:

  1. The combination with LDAP authentication hasn't been tested yet.
  2. Kerberos is just an authentication method and not user management. Implementors will need to setup user mappings via modules/server/login-kerberos.xml and modules/ldap/sync-party.xml on top.
  3. The complete server side setup needs a Service Principal Name from the Kerberos Domain Controller, as well as a keytab file as described here.

SAML-SSO

This authentication method can be selected in the System asset by choosing the "SAML" option. The architecture and configuration details of SAML are thoroughly explained in "SAML-SSO Essentials".

The client's GET requests are handled by:

    HttpServlet.service()->DeliveryServlet.doGet()->AuthenticationManager.handleRequest()->invalidAuth()

The identity of the provider via POST or GET reply is handled by:

    HttpServlet.service()->DeliveryServlet.doGet();
    // or
    HttpServlet.service()->DeliveryServlet.doPost()

Notes:

There is an additional hook into LDAP. This is to map SAML logins to a large set of domains/roles/groups/languages by checking an LDAP server. Normally this mapping works with a censhare XSLT.

External (via Servlet)

This authentication method works via a customer/partner developed servlet.

The AuthenticationManager fowards request to the ExternalAuthenticationServlet below like this:

    dispatcher = request.getRequestDispatcher("/extAuth/*");
    dispatcher.forward(request);

whenever "External (via Servlet)" and "Standard" is set on the System asset authentication methods. Note that there is no other HTTP redirect involved on censhare side.

Template code for creating a custom Servlet can be found in app/modules/external_authentication/.

The URL pattern is setup in app/modules/external_authentication/ExternalAuthenticationServlet.java:

    @WebServerServlet(name = "External Authentication (servlet-based)", urlPatterns = {"/extAuth/*"})

Online Channel-SSO

Users who are authenticated in Online-Channel can automatically reuse their sign-on with censhare-Server.

This is done in the AuthenticationManager:

ssoTreatment(request, response, isAuthenticated);

An internal test system has been setup. Please ask support for details.

HTTP Basic

This authentication method is being handled by the DeliveryServlet and the AuthenticationManager:

doGet() -> handleRequest() -> invalidAuth()

Token based

The client's login entry point is handled by app/modules/custom_authentication/CustomLoginServlet.java where the URL pattern can be defined:

@WebServerServlet(name = "Custom Authentication (token-based)", urlPatterns = { "/customAuth/*" })

Seemingly a development for a specific customer who used the same mechanism before with GWT WebClient.

Removed: HTTP Digest

Removed since version 5.8 for security considerations (usage of MD5). We highly recommend to use HTTP Basic instead.

REST

  • REST API entry: com/censhare/manager/httpserver/servlet/RestServlet.java
private final static String REST_URL_PATTERN = "/rest"; // TODO: Add to url pattern when soap has removed

The authentication is handled via com/censhare/server/webservice/AuthenticationFilter.java, and it implements the following:

  • HTTP Basic
  • HTTP Digest
  • Cookie value of censhare.session

Notes

Currently available login modules:

$ censhare-Server/app/modules/server > ls -1 login*xml
login-custom.xml
login-http-auth.xml
login-kerberos.xml
login-private-public-key.xml
login-standard.xml
login-ticket.xml

We do HTTP 301 from path "censhare5/client" to "censhare5/client/"