Introduction

Certificates can be used for mutual authentication:

  • The client (Browser Client, REST Client) challenges the JOC Cockpit server to present its server authentication certificate that will be verified by the client.
  • The JOC Cockpit server challenges the client to present its client authentication certificate that is verified by JOC Cockpit.

With JOC Cockpit being set up for mutual authentication the certificates can be used

  • to enforce two-factor authentication with clients having to provide a certificate and a password,
  • to allow single-factor authentication using a certificate instead of a password.

Prerequisites

Consider that JOC Cockpit has to be set up for JOC Cockpit - HTTPS Mutual Authentication - Two-factor Authentication.

Configuration with Shiro

Single-factor authentication boils down to use either account/password authentication or to allow certificate based authentication alternatively.

JOC Cockpit makes use of Shiro for authentication management. Therefore changes have to be applied to the shiro.ini configuration file:

  • On Windows systems the default location for the shiro.ini file is:
  • On Unix systems the default location will be:


Example for shiro.ini configuration
[users]
root = $shiro1$SHA-512$500000$W0oNBkZY9LRrRIGyc4z2Ug==$NcoU+ZFM9vsM0MeHJ3P5NJ0NdvJrK38qVnl7v7YG7p9o5ZJfMccugJsA9myJsTNx2BF5rbvA696UhTGdUtSnOg==,all
apmacwin = ,all

[main]
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
iniRealm.credentialsMatcher = $passwordMatcher

certRealm = com.sos.auth.shiro.SOSX509AuthorizingRealm
securityManager.realms = $iniRealm,$certRealm

# Session timeout in milliseconds
securityManager.sessionManager.globalSessionTimeout = 3600000

Explanations:

  • The [users] section holds
    • accounts that are assigned a password hash and a number of roles,
    • accounts that are assigned a number of roles but not a password. If no password is specified then
      • the password can be specified by the user if an LDAP Configuration is in place with the [main] that will verify the password towards an LDAP Directory Server, e.g. Microsoft Active Directory®.
      • the password can be omitted if a certificate configuration is in place with the [main] section.
  • The [main] section holds two lines for the certificate configuration:
    • certRealm = com.sos.auth.shiro.SOSX509AuthorizingRealm
      securityManager.realms = $iniRealm,$certRealm
    • Consider the sequence of realms specified:
      • With the above configuration
        • first the account used for login will be checked for a matching entry with a password from the [users] section. This translates to the fact that for such accounts two-factor authentication is required as both a certificate and a password have to be specified.
        • then alternatively the account used for login will be checked if it provides a client authentication certificate. 
      • The sequence of realms can be modified and use of the $iniRealm can be dropped if no login with passwords should be enabled.


  • No labels