You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

Defining a JWT authentication provider

In the application.properties file, these properties are expected for a JWT authentication provider:

application.properties

# Global configuration
blueriq.security.login-type = jwt

# Auth-provider type declaration
blueriq.security.auth-providers.jwt.type = jwt

# JWT decoder, below is an OpenId Connect with keycloak example 
spring.security.oauth2.resourceserver.jwt.jwk-set-uri = https://<KEYCLOACK>:<port>/realms/<YOUR_REALM>/protocol/openid-connect/certs

# Add the JWT authentication provider to the chain
blueriq.security.auth-providers-chain = jwt

For the available JWT decoder settings see: https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/jwt.html

Token validation

Since 16.8 the JWT Authentication provider validates tokens per request basis. This is done according the following the mechanism.

  1. Verify if the request token is the same as the token that is stored in the http session.
  2. Verify if the request token is not already expired.
  3. Verify if the mapped claims of the request token are the same as the claims of the token stored in the http session.

If any of these verification steps fail, Blueriq will invalidate the http session. Blueriq cannot guarantee that are no side effects in the current Blueriq session when we use updated claims of a new token. For example when new roles or teams are added to that token, one might say that this is compatible, however the user is in a certain state of the application that expects the same roles and teams are present as during the initialization of Blueriq session.  

Validated an accepted tokens will be updated in the Http Session, in order to support long living downstream calls to other applications using the same token.


Configuration

SubjectJAVA PropertyExplanation
JWT Authenticationblueriq.security.jwt.login-path

Optional login path property that is used when building the login redirect URL to the Gateway Service. This can be overridden when the Gateway Service is running behind a reverse proxy.

Default: /login

application.properties


blueriq.security.jwt.logout-path

Optional logout path property that is used when building the logout redirect URL to the Gateway Service. This can be overridden when the Gateway Service is running behind a reverse proxy.

Default: /logout

application.properties


blueriq.security.jwt.sso-logout

Boolean indicating whether when logging out of Blueriq the user should be logged out of the Single-Sign-On session as well.

Default: false

application.properties

Claims mapping

The following configuration properties can be used to extract information from the JWT claims:

SubjectJAVA PropertyExplanation

blueriq.security.jwt-claims.roles-path

A JsonPath expression to the roles claim in the JWT body. 

For example, if the JWT body contains below claims, this property should be set to $.realm_access.roles in order to indicate that the roles claim nested within the realm_access claim represents the roles. 

{
  ... other claims ...
  "realm_access": [
    "roles": ["role1", "role2"]
  ]
  ... other claims ...
}


application.properties


blueriq.security.jwt-claims.teams-path

A JsonPath expression to the teams claim in the JWT body. 

See roles-path above for more information.

application.properties


blueriq.security.jwt-claims.role-mapping.<role-claim>

Maps a role claim to zero, one or multiple Blueriq roles. If a role claim does not have a mapping, it is considered to have an implicit identity mapping.

Example: blueriq.security.jwt-claims.role-mapping.employee=authenticated_user,vu_employee

(all users which have the employee role at the identity provider will have the authenticated_user and vu_employee roles in Blueriq)

application.properties


blueriq.security.jwt-claims.team-mapping.<team-claim>

Maps a team claim to zero, one or multiple Blueriq teams. If a team claim does not have a mapping, it is considered to have an implicit identity mapping.

Example: blueriq.security.jwt-claims.team-mapping.amsterdam=europe,netherlands

(all users which have the amsterdam team at the identity provider will have the europe and netherlands teams in Blueriq)

application.properties


blueriq.security.jwt-claims.username-path

A JsonPath expression to the usernameclaim in the JWT body. 

See roles-path above for more information.

If no value is specified, the default value is used: $.preferred_username.

application.properties


blueriq.security.jwt-claims.claim-mapping.<key-id>=<value>

Additional optional custom parameter to retrieve a claim from the JWT and place it in the Authentication under the specified key. The value should be a JsonPath expression to the claim in the JWT body.

Only (lists of) strings, numbers and booleans are supported. These values will all be converted to strings.

See roles-path above for more information.

These claims can be retrieved to the profile using the GetAuthenticationClaims service.

application.properties

Limitations

  • Currently, when using JWT as an authentication provider, no other authentication provider on the chain will work.
  • Only KeyCloak with OpenIdConnect is supported


Development Dashboard

When using the Oauth JWT Authentication Provider the Development Dashboard will redirect unauthenticated users (when authentication is required) to the Blueriq Gateway Service as its source of authorization. More information regarding the Development Dashboard flow can be found here.

Audit logging

The audit log is built to log login requests from the Runtime. When the JWT login type is used, the user never requests to login at the Runtime, but another component outside the Blueriq Platform facilitates this. Therefore, login attempts cannot be not audit logged. Please make sure the login provider (for example Keycloak) is set to log authentication requests for audit purposes.