You are viewing the documentation for Blueriq 13. Documentation for other versions is available in our documentation directory.
The Blueriq Runtime deliveres an out-of-the-box in-memory authentication provider. These default implementations should only be used for development purposes as they store the credentials in plain text on the filesystem.
Runtime configuration
The Runtime reads the authentication configuration from Spring environment properties, under the covers Spring Security is used. In the Runtime one Spring Security AuthenticationManager bean named blueriqAuthenticationManager is registered, defined in com.aquima.web.boot.SecurityConfiguration. An anonymous authentication provider is added by default (hardcoded), this is used for anonymous access.
Blueriq supports an in-memory authentication provider type and a customBean authentication provider type for custom authentication needs. Multiple authentication providers can be chained. Every authentication provider must have a unique name, this name is also used in the auth-providers-chain property to determine the order of the authentication providers in the chain.
Properties
Like all security properties, the authentication properties are prefixed with blueriq.security. For every authentication provider a type must be specified,
it can be in-memory or customBean or LDAP. Checkout these pages on how it works:
Chain: Specifying which authentication providers to use
Only authentication providers specified in the blueriq.security.auth-providers-chain property will be used by the Blueriq Runtime. The providers will be tried in the order they are specified in the chain. A warning will appear in the Blueriq Runtime log when no authentication providers are specified in the chain.
Example of authentication providers chain using two out of three specified providers:
application.properties
blueriq.security.auth-providers.local01.type=in-memory blueriq.security.auth-providers.local01.users.location=users.properties blueriq.security.auth-providers.myAuthProvider01.type=customBean blueriq.security.auth-providers.myAuthProvider02.type=customBean # add any provider to this chain, can be multiple ldap / in-memory / customBean blueriq.security.auth-providers-chain=myAuthProvider01,local01
Logout
Example request:
Sample request
POST http://localhost/runtime/api/v1/logout HTTP/1.1
The response will be a simple 204 status code.
For version 2 of the API, the logout endpoint can support redirect URL parameter, and if the parameter is set then the endpoint will send a 302 status code with the location to the redirect parameter instead of the normal 204 status code.
Example request without redirect URL:
Sample request
POST http://localhost/runtime/api/v2/logout HTTP/1.1
The response will be a simple 204 status code.
Example request with redirect URL:
Sample request
POST http://localhost/runtime/api/v2/logout?redirect_uri=http://example.frontend.com/logged-out.html HTTP/1.1
The response will be a 302 status code and the location will be set to the value received in the redirect_uri parameter:
HTTP/1.1 302 Found Location: http://example.frontend.com/logged-out.html
If OpenID Connect is used in the Runtime and SSO Logout is enabled, then Runtime will redirect to the identity provider's logout endpoint and send the redirect_uri parameter to the identity provider.
HTTP/1.1 302 Found Location: http://identity.example.com/sso/logout?post_logout_redirect_uri=http://example.frontend.com/logged-out.html
After the identity provider logs out the user, it will redirect to the original URL:
HTTP/1.1 302 Found Location: http://example.frontend.com/logged-out.html
Logout URL whitelist
For security reasons a new property where all the allowed redirect URLs can be specified:
blueriq.security.logout-redirect-url-whitelist=url1,url2
The URLs specified in the whitelist are case sensitive and represent only the prefix of the URL.
If login type is set for openid-connect, then a redirect_uri parameter must be present when calling the logout endpoint.
Overview
Content Tools