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

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.