JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 9

changes.mady.by.user Uwe Risse

Saved on

compared with

New Version 10

changes.mady.by.user Uwe Risse

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

  • Realms/Tokens
    • Client Session Idle: After this idle time a token will expire. 20s before reaching this time the token will be renewed by JOC Cockpit automatically.
    • Client Session Max: After this time a token can no longer be renewd. It is recommended to set this value to a larger value then the session timeout configured in JOC Cockpit.
    • SSO Session Idle: When Client Session Idle is not set
    • SSO Session Max: When Client Session Max is not set
  • Keycloak access tokens are created with the following restrictions:
    • time to live (TTL):
      • the access token will expire after the given period ,(Session Idle)
      • the Identity Service renews the access token 20s before expiration, this step is performed for an arbitrary number of renewalsuntil Session Max is reached. This requires that the access token's TTL exceeds 60s and the 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 (Session Max), 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 (Session Idle), maybe not less than 300s, and the maximum TTL (Session Max), 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.

...

  • Keycloak URL: the base URL for which the Keycloak REST API is available. 
  • Keycloak Administration Account: A Keycloak Account with the admin role that have at least the roles . This account is used to retrieve the roles for a Keycloak account and for renewing access tokens.
  • Keycloak Administration Password: The password for the Keycloak Administration Account.
  • Keycloak Truststore Path:  Should the 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 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.
  • Keycloak Truststore Password: If the Keycloak Server is configured for HTTPS connections and the indicated truststore is protected by a password then the password has to be specified.
  • Keycloak Truststore Type: If the Keycloak Server is configured for HTTPS connections then the type of the truststore has to be specified being either PKCS12 or JKS (deprecated).
  • Keycloak Clients are entities that request Keycloak to authenticate a user account. For example, an application such as JOC Cockpit or service acts as a Client to the Keycloak server. Clients use Keycloak to authenticate and to provide a single sign-on solution.
    • Keycloak Client ID and Keycloak Client Secret are used for 
      • requesting a valid token
        • for user authentication,
        • for admin access,
      • validating an existing token,
      • renewing an existing valid token.
    • Keycloak Client Secret: The Client has a secret which needs to be known by both the Keycloak server and the JOC Cockpit.
  • Keycloak Realm: A realm manages a set of users, credentials, roles, and groups. A user belongs to a realm and performs a login to a realm. Realms are isolated from each other and manage and authenticate exclusively user accounts that they control.

...