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.
- Verify if the request token is the same as the token that is stored in the http session.
- Verify if the request token is not already expired.
- 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
| Subject | JAVA Property | Explanation | |
|---|---|---|---|
| JWT Authentication | blueriq.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 |
|
| 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 |
| |
| 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 |
|
Claims mapping
The following configuration properties can be used to extract information from the JWT claims:
| Subject | JAVA Property | Explanation | |
|---|---|---|---|
| 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 {
... other claims ...
"realm_access": [
"roles": ["role1", "role2"]
]
... other claims ...
}
|
| |
| blueriq.security.jwt-claims.teams-path | A JsonPath expression to the teams claim in the JWT body. See roles-path above for more information. |
| |
| 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) |
| |
| 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) |
| |
| 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: |
| |
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. |
|
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.
Overview
Content Tools