Skip to main content
Version: Next

Security configuration

Jadice flow supports different modes of web security: none, basic and oauth2. Lets first look at the components:

  • jf-controller: The base rest controller which handles JobRequest requests
  • jf-controller-ui: The vaadin UI. Sends request to controller via java client.
  • flow java client - for source scanner or other external services (and UI)

The different security configurations are applied via application.yml / values.yml. Lets now look at each component in detail.

jf-controller

security modes​

No security mode​

No security mode can be used in secure environments where no ports are exposed or for testing.

application.yml:

security.mode: none

HTTP Basic authentication​

Basic authentication can be enabled in the jf controller. It will use pre-defined users from configuration. To enable it, add this to the application.yml:

security.mode: basic

local-user-management:
  users:
  - name: admin
    password: "{noop}password"
    roles:
    - ADMIN

This will add the "admin/password" user. More users can be added to this users list if desired. The password can be encoded. See Spring Password storage Documentation for more infos of supported algorithms.

OAuth2 Authentication​

See OAuth requirements section for configuring the users in your keycloak instance.

To enable OAuth in controller, activate it by providing:

security.mode: oauth

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: jadice-flow-controller
            authorization-grant-type: jwt-bearer
            client-authentication-method: none
            scope: openid, profile, email
        provider:
          keycloak:
            # Attention: If using using an old keycloak, it might have "/auth/" in the path.
            # In newer keycloak versions, the url starts at "/realms/"
            issuer-uri: https://my-OldVersion-keycloak/auth/realms/jadice-flow
      resourceserver:
        jwt:
          issuer-uri: ${spring.security.oauth2.client.provider.keycloak.issuer-uri}

Hint If any security mode like BASIC or OAUTH is enabled, the spring boot actuator might also be affected from spring security (so users have to log in or have a token to access it). In some cases, it is desired to have the actuator public available (e.g. if it runs on management port anyway).

The controller supports this by adding:

security.publicActuatorEndpoint: true

The spring boot actuator is then accessible without authentication.

jf-controller-ui

security modes​

No security mode​

No security mode can be used in secure environments where no ports are exposed or for testing.

application.yml:

security.mode: none

HTTP Basic authentication​

Basic authentication can be enabled in the jf controller UI. It will use pre-defined users from configuration. To enable it, add this to the application.yml:

security.mode: basic-vaadin

local-user-management:
  users:
  - name: admin
    password: "{noop}password"
    roles:
    - ADMIN

Users will login to the UI via an internal login page.

OAuth2 authentication​

See OAuth requirements section for configuring the users in your keycloak instance.

To enable OAuth in controller-ui, activate it by providing:

security.mode: oauth-vaadin

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: jadice-flow-ui
            authorization-grant-type: authorization_code
            client-authentication-method: none
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
            scope: openid, profile, email
        provider:
          keycloak:
            # Attention: We are using an old keycloak with "/auth/" in the path.
            # In newer keycloak versions, the url starts at "/realms/"
            issuer-uri: https://my-OldVersion-keycloak/auth/realms/jadice-flow

Users will be redirected to keycloak to perform login and will be redirected back.

Note When using "oauth-vaadin" mode, the current oauth token of the logged in user will also be used as token provider, if oauth is enabled in the client configuration.

flow java client (spring)

The flow java client is also used in the UI. So this part is also relevant for:

  • jf-controller-ui
  • jf-source-scanner

Java clients are mostly background services so they use a service account.

In flow, we can set these client configurations.

none​

No security mode configuration:

application.yml:

jadice-flow.client.security.mode=none

Basic auth​

Basic authentication will use the configured user to access the server.

application.yml:

jadice-flow.client.security.mode: basic
jadice-flow.client.basic-auth.username: admin
jadice-flow.client.basic-auth.password: password

in theory, it is possible to configure the UI to use oauth, and the controller to use basic auth. In such case, the above configuration can be used to authenticate via basic auth at the controller.

OAuth​

OAuth2 can be enabled with the following configuration:

application.yml:

# OAuth Client config to access controller:
# Usually the same. But you can also use oauth on client here and basic auth above for UI in theory for example 
jadice-flow.client.security.mode: oauth

OAuth2Config:
  enabled: true
  resourceName: jadice-flow-sa
  auth-grant-type: client_credentials
  token-url: https://my-OldVersion-keycloak/auth/realms/jadice-flow/protocol/openid-connect/token
  client-secret: abcdefg123_client_secret

This configuration will use the jadice-flow-sa (service account) user with the given client secret.

Hint In theory its possible to enable basic auth in the UI, but oauth on controller. In such case, the above config could be used to use the service account user for oauth authentication. Preferred is to use same authentication method on all sides.

Keycloak configuration

Lastly, lets look how to initially setup keycloak...

When using oauth, a keycloak server can be used to act as OAuth resource server. It can also be configured to proxy LDAP users in the background. See the keycloak documentation for details.

Here we will focus on the required / recommended default users.

Create a realm for jadice flow, e.g. "jadice-flow".

We generally need these 3 users:

jf-controller​

Controller uses bearer-only and requires token to be present.

  • client-id: jadice-flow-controller
  • client protocol: openid-connect
  • access type: bearer-only

jadice-flow-ui​

UI user for interactive login:

  • client-id: jadice-flow-ui
  • client protocol: openid-connect
  • access type: public
  • standard flow enabled: true
  • implicit flow enabled: false
  • direct access grants: true

Also important: Set the valid redirect URLs, otherwise the login cannot redirect back. For testing, its e.g. "http://localhost:8090/*" when running UI locally. In your environment, its the UI reference URL. Also keep an eye on HTTP vs HTTPS. If SSL is enabled, https is being used.

jadice-flow-sa​

For example this "jadice-flow-sa" (service account) user. It is also possible to give each background components (like source scanner etc) their own service account.

  • client-id: jadice-flow-sa
  • client protocol: openid-connect
  • access type: confidential
  • standard flow enabled: true
  • implicit flow enabled: false
  • direct access grants: true
  • service accounts enabled: true

Credentials tab: Shows client secret to use in configuration.

SSL / TLS Configuration

This section describes how to setup SSL in a local / all-in-one environment. For kubernetes, this is usually already done by the load balancer. But if for example certbot shall be used, certificate+privKey File can be imported.

For test environments, a self-signed certificate can be generated.

Enable SSL with default SSL settings. Keystore will be created if not present.

The following SSL configuration can be enabled in controller and / or controller-ui.

UI config (will autoImport generated cert of controller):

# Default SSL settings
server:
  ssl:
    key-store-type: PKCS12
    key-store: ${user.dir}/jf-keystore.p12
    key-alias: jf-keystore
    key-store-password: jf-keystore-pw-42

# Auto-cert SSL settings
# keystore-init can generate a self signed cert and / or import SSL certificates from trusted environments into the truststore.
# 
keystore-init:
  enabled: true
  forceTruststoreImport: true
  forceKeystoreImport: false
  # You can provide an external cert and private key file here. If empty, a self-signed certificate will be generated
  #certFile:
  #privKeyFile:   
  generatedCertCNname: localhost
  generatedCertDomainName: localhost
  # Mainly for secure / trusted environments; e.g. we need to import the generated cert of controller into the UI
  autoImportURL: https://localhost:8080

(Server/controller side config is the same, but without autoImport).

Keystore-init has these properties:

  • enabled : To generally enable / disable this functionality
  • forceTruststoreImport : Whether to force importing autoImportURLs on every start. If false (=default), cert will only be loaded if invalid / not existent. Otherwise loaded on each startup.
  • forceKeystoreImport : Whether to force importing certFile and privKeyFile on every start. If false (=default), cert will only be loaded if invalid / not existent. Otherwise loaded on each startup.
  • certFile : Certificate file to import (leave empty for self signed generation)
  • privKeyFile : Private key file to import (leave empty for self signed generation)
  • generatedCertCNname : common name (CN) of the certificate
  • generatedCertDomainName : domain name of the certificate
  • autoImportURL : Preferred is to provide a keystore externally. But in autoImportURL, we can trust any SSL connection and load the cert into the truststore. Add URLs to be trusted automatically. (dashed list below entry)
Last updated on by David Hoffmann