Page History

...

• The JS7 - Identity Services offer integration with HashiCorp® Vault authentication server.
• The Vault Identity Service integration is available from JOC Cockpit:
  • This requires HashiCorp® Vault to be downloaded, installed and operated by the user. Vault is not a built-in identity service Identity Service and does not ship with JS7.
  • JS7 implements a REST client for use with HashiCorp® Vault 1.7.0 and newer.

...

• Service Type: VAULT
  • Management of user accounts and passwords is performed with the Vault Server.
  • In addition, an automated mapping of policies - assigned a user account in Vault - to JOC Cockpit roles takes place.
  • JOC Cockpit does not know any user accounts, passwords an and role assignments as this information is managed with Vault only.
• Service Type: VAULT-JOC
  • Management of user accounts and passwords is performed with the Vault Server.
  • The assignment of roles to user accounts is performed with JOC Cockpit and is stored with the JS7 database.
  • JOC Cockpit knows user accounts and role assignments. JOC Cockpit does not know passwords as this information is managed with Vault only
• Service Type: VAULT-JOC-ACTIVE
  • Management of user accounts and passwords is performed with JOC Cockpit. JOC Cockpit forwards user accounts and passwords to the Vault Server. JOC Cockpit stores users accounts (not: passwords) in the JS7 database.
  • The assignment of roles to user accounts is performed with JOC Cockpit and is stored with the JS7 database.
  • JOC Cockpit knows user accounts and role assignments. JOC Cockpit temporarily knows passwords until this information is forwarded to Vault.

...

• Username & Password
• LDAP
  • It is not required to use Vault 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 VAULT identity service type Identity Service Type only.

JS7 does not support cloud based authentication methods with Vault as such methods are typically used for engineering and administration administrative roles with cloud services that are not related to an application such as JS7.

...

Anchor
application_role application_role

Application Role

If the VAULT-JOC-ACTIVE identity service type Identity Service Type is used then an Application Role has to be created and a an access token has to be generated with Vault that is added to the JOC Cockpit configuration of the Vault identity serviceIdentity Service.

Tokens Access tokens created for the Application Role have to include Vault permissions to manage user accounts if the Username & Password authentication method is used

...

• The authentication method has to be added to Vault.
  • The path of the authentication method has to be added to the Identity Service configuration in JOC Cockpit identity service configuration.
• If the VAULT identity service type Identity Service Type is used then
  • user accounts are managed exclusively with Vault,
  • policies have to be set up in Vault with names that exactly match the names of roles in JOC Cockpit.
    • a user account will be assigned the roles matching policy names when performing a login to JOC Cockpit.
    • it is not required to add specific permissions to policies with Vault.
• If the VAULT-JOC identity service type Identity Service Type is used then
  • user accounts are managed with Vault.
  • user accounts are added to JOC Cockpit to allow assignment of roles:
    • user accounts in Vault an and in JOC Cockpit have to match as otherwise the user account is not assigned a role.
    • no passwords are managed by JOC Cockpit.
• If the VAULT-JOC-ACTIVE identity service type Identity Service Type is used then
  • user accounts are managed with JOC Cockpit and are stored with Vault.
  • user accounts are assigned roles with JOC Cockpit.

...

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

...

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

• Vault access tokens are created with a restriction of the
  • 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 the access token's TTL to exceed 60s and the Vault permission self to renew a token by the token owner to be in place.
  • maximum time to live
    • the access token's overall lifetime is limited, no renewals can 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 case that the maximum TTL is exceeded and in case that the token is revoked.
  • Vault 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.
• Independently from Vault the JOC Cockpit handles the idle timeout of user sessions, see JS7 - Identity Services.
  • If the idle timeout is exceeded then the user session is terminated.
  • The Identity Service tries to revoke the access token. This requires the Vault permission self to revoke a token by the token owner. 
• The Identity Service does not make use of Vault child tokens.

...

JOC Cockpit offers the Manage Identity Services view page from the user menu of an administrative account for configuration of Identity Services:

...

To add an Identity Service use the button Add Identity Service from the above list of page that lists available Identity Services:

The remaining input fields for the popup window look like this:

...

• The Identity Service Name is a unique identifier that can be freely chosen.
• The Identity Service Type can be selected as available from the above matrix.
• The Ordering specifies the sequence in which a login is performed with available Identity Services.
• The Required attribute specifies if login with the respective Identity Service is required to be successful, for example if a number of Identity Services are triggered on login of a user account.
• The Identity Service Authentication Scheme allows to select
  • single-factor authentication: user account and password are specified for login with the Identity Service.
  • two-factor authentication: in addition to user account and password a Client Authentication Certificate is required, see JS7 - Certificate based Authentication.

Identity Service Settings

...

• Vault URL: the base URL for which the Vault REST API is available.
• Vault Authentication Method Path: the path specifies the Vault Authentication Method to be used, see chapter Authentication Methods.
• Vault Truststore Path:  Should the Vault Server be configured for HTTPS connections then the indicated truststore has to include an X.509 certificate specified for the extended key usage 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 Certificate has to be available with the truststore.
  • If the Vault Server is operated for HTTPS connections and this setting is not specified then 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. 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 specify the file name only is specified, typically with a .p12 extension. Other relative locations can be specified using e.g. ../../joc-truststore.p12 if the truststore is located in the JETTY_BASE directory. No absolute path can be specified and no path can be specified that lies before the JETTY_BASE directory in the file system hierarchy.
• Vault Truststore Password: Should the Vault Server be configured for HTTPS connections and the indicated truststore be protected by a password then the password has to be specified.
• Vault Truststore Type: Should the Vault Server be configured for HTTPS connections then the type of the indicated truststore has to be specified being either PKCS12 or JKS (deprecated).
• Vault Application Token: The application token setting is available only if the VAULT-JOC-ACTIVE Identity Service Type is used.
  • JOC Cockpit requires this token in order to manage users with Vault, the token has to be created with Vault, see above chapter Application Role. This token allows JOC Cockpit to access the Vault REST API to manage user accounts.
  • This token is not used for login of users.  

...