You are viewing the documentation for Blueriq 15. 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

Claim mapping

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

SubjectJAVA PropertyExplanation

blueriq.security.openid-connect.roles-path

The comma-separated path to the roles claim in the JWT body. For example if the JWT body contains the following claims:


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

then 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 user's roles.

application.properties


blueriq.security.openid-connect.teams-path

The comma-separated path to the teams claim in the JWT body. See roles-path above for an example.

application.properties


blueriq.security.openid-connect.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.openid-connect.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.openid-connect.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.openid-connect.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.openid-connect.username-path

The comma-separated path to the username claim in the JWT body. For example if the JWT body contains the following claims:

{
  ... other claims ...
  "realm_access": [
    "nickname": "username"
  ]
  ... other claims ...
}

then this property should be set to "realm_access,nickname" in order to indicate that the nickname claim nested within the realm_access claim represents the username.

Auth0 will include the claim nickname in the JWT body when the scope profile is added to the list of scopes. We suggest to set this property to "nickname" when using Auth0.

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

application.properties


blueriq.security.openid-connect.claim-mapping.<key-id>=<value>

Additional optional custom parameter to retrieve a claim from the openid-connect JWT token en place it in the Authentication.

For more information see the openid connect configuration page.

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 KeyCloack with OpenIdConnect is supported
  • Tokens will only be checked/validated at the start of an HTTP-session
  • No labels