...

The following integration levels are available from Identity Service Types that can be used with VaultKeycloak:

...

JS7 supports the following authentication methods with VaultKeycloak:

• Username & Password
• LDAP
  • It is not required to use Keycloak to connect to an LDAP Directory Service as there is a built-in JS7 - LDAP Identity Service for this purpose.
  • This authentication method can be used with the KEYCLOAK Identity Service Type only.

...

• It is not necessary to use Vault Keycloak to connect to an LDAP Directory Service as there is the built-in JS7 - LDAP Identity Service for this purpose.
• The authentication method has to be added to VaultKeycloak.
  • The path of the Authentication Method has to be added to the Identity Service configuration in JOC Cockpit.
• The KEYCLOAK Identity Service Type has to be used, meaning that:
  • user accounts are managed with Keycloak.
  • user accounts are added to the JOC Cockpit to allow assignment of roles:
    • user accounts in Keycloak and in the JOC Cockpit have to match as otherwise the user account is not assigned a role.
    • no passwords are managed by the JOC Cockpit.

...

When a user logs in to the JOC Cockpit then user credentials are forwarded to the Keycloak Server that authenticates the user and returns an access token.

• Vault access Keycloak access tokens are created with the following restrictions:
  • time to live (TTL):
    • the access token will expire after the given period,
    • the Identity Service renews the access token 60s before expiration, this step is performed for an arbitrary number of renewals. This requires that the access token's TTL exceeds 60s and the Vault permission self for Keycloak permission for renewing a token by the token owner to be in place.
  • maximum time to live:
    • the access token's overall lifetime is limited, renewals cannot take place after the specified period.
• If an access token cannot be renewed by the Identity Service then the user session is terminated and the user is forced to login and to specify credentials.
  • This happens in the event of the maximum TTL being exceeded or that the token has been revoked.
  • Keycloak administrators should check for reasonable values of the TTL, maybe not less than 300s, and the maximum TTL, maybe at least 15 minutes, as otherwise users would have to repeatedly login quite frequently.
• The JOC Cockpit handles the idle timeout of user sessions independently of Keycloak, see JS7 - Identity Services.
  • If the idle timeout is exceeded then the user session is terminated.
  • The Identity Service can revoke the access token with the Keycloak server.

...

• the Keycloak product has to be installed and has to be accessible for JOC Cockpit and
• the following settings have to be specified: 
  
  

Explanation:

• Keycloak URL: the base URL for which the Vault Keycloak REST API is available.
• Vault Authentication Method Path: the path specifies the Vault Authentication Method to be used, see the Authentication Methods section above.
• Keycloak Administration Account: 
• Keycloak Administration Password: 
• Keycloak Vault Truststore Path:  Should the Vault Keycloak Server be configured for HTTPS connections then the indicated truststore has to include an X.509 certificate specified for the Extended Key Usage of Server Authentication.
  • The truststore can include a self-signed certificate or a CA signed certificate. Typically the Root CA certificate is used as otherwise the complete certificate chain involved in signing the Server Authentication Certificate has to be available with the truststore.
  • If the Vault Keycloak Server is operated for HTTPS connections and this setting is not specified then the JOC Cockpit will use the truststore that is configured with the JETTY_BASE/resources/joc/joc.properties configuration file. This includes use of settings for the truststore password and truststore type.
  • The path to the truststore is specified relative to the JETTY_BASE/resources/joc directory. If the truststore is located in this directory then only the file name is specified, typically with a .p12 extension. Other relative locations can be specified using, for example, ../../joc-truststore.p12 if the truststore is located in the JETTY_BASE directory. An absolute path cannot be specified and a path cannot be specified that lies before the JETTY_BASE directory in the file system hierarchy.
• Vault Keycloak Truststore Password: If the Vault the Keycloak Server is configured for HTTPS connections and the indicated truststore is protected by a password then the password has to be specified.
• Vault Keycloak Truststore Type: If the Vault the Keycloak Server is configured for HTTPS connections then the type of the truststore has to be specified being either PKCS12 or JKS (deprecated).Vault Application Token:
• Keycloak Client ID:  
• Keycloak Client Secret  
• Keycloak Realm   The application token setting is available only if the VAULT-JOC-ACTIVE Identity Service Type is used.
• The JOC Cockpit requires this token in order to manage users with Vault. This token has to be created with Vault, see the Application Role section above. This token allows JOC Cockpit to access the Vault REST API to manage user accounts.
This token is not used for login of users.  

Logging

• Log Files
  • See JS7 - Log Files and Locations
• Standard Log Files
  • Identity Services log output to the JETTY_BASE/logs/joc.log file. This includes reporting success or failure of authentication.
  • Successful and failed authentication attempts including the user accounts involved are logged to the JETTY_BASE/logs/audit.log file.
• Debug Log Files
  • For problem analysis during setup of an Identity Service increase the log level as explained with JS7 - Log Levels and Debug Options.
  • The JETTY_BASE/logs/joc-debug.log file includes general debug output of JOC Cockpit.
  • The JETTY_BASE/logs/authentication-debug.log file includes debug output related to authentication and authorization.
  • The JETTY_BASE/logs/jetty.log file includes debug output of attempts to establish SSL connections.

...