You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Exposed Blueriq REST services can accept OpenID Connect access tokens for authentication, with the following restrictions:
- access tokens must be in the signed JWT format
- access tokens must contain user information (username, roles, teams)
Example request:
GET http://example.com/Runtime/server/rest/ExampleShortcut/ExampleService HTTP/1.1 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Some identity providers may require configuration or extra parameters in the original authorization request in order to issue JWT access tokens. For example, see auth0.com Access Token Documentation on how auth0.com can be configured to issue JWT access tokens.
Most identity providers also allow configuring the claims included in identity tokens, access tokens and the response from the userinfo endpoint. If for some reason it is not possible to configure the identity provider to issue JWT access tokens, then a custom BaaS Flow Starter [editor] may be implemented which reads the opaque access token from the Authorization header and calls the userinfo endpoint to obtain the user information. See OpenID Connect UserInfo Endpoint Specification for more details about the userinfo endpoint.
When using the default BaaS Flow Starter, the authenticated user is available in the system.user entity instance. The access token received in the Authorization header will be forwarded to external REST services called via an AQ_RestServiceClient configured with an HTTP connection that uses openid-connect authentication. See 05 AQ_RestServiceClient [editor] for more information.
Configuration
BAARS itself does not require any specific configuration. However, the following general OpenID Connect configuration options apply:
- the Runtime must be configured to use OpenID Connect login type
- the OpenID Connect properties must be correctly configured so the received JWT access token can be validated (in particular, the issuer and the public keys)
- an OpenID Connect authentication provider must be defined and included in the authentication provider chain
Example configuration:
# the Runtime must be configured to use OpenID Connect login type blueriq.security.login-type=openid-connect # OpenID Connect properties must be configured blueriq.security.openid-connect.token-issuer=http://example.com/auth/realms/master blueriq.security.openid-connect.keys-endpoint=http://example.com/auth/realms/master/protocol/openid-connect/certs blueriq.security.openid-connect.user-discovery=true blueriq.security.openid-connect.client-id=example-client blueriq.security.openid-connect.roles-path=realm_access,roles blueriq.security.openid-connect.teams-path=teams # ... and other OpenID Connect properties required for user interactions projects # an OpenID Connect authentication provider must be defined blueriq.security.auth-providers.oidc.type=openid-connect # the OpenID Connect authentication provider must be added to the authentication provider chain blueriq.security.auth-providers-chain=provider1,oidc,provider2
Secured BAARS Endpoints and Basic Authentication
BAARS endpoints accept and use authentication information even if the endpoints are not secured. Securing an endpoint simply means that authentication is required, Leaving an endpoint unsecured means that authentication is optional. For example, if an unsecured endpoint is called without providing authentication, the system.user entity instance will be the anonymous user. However, if authentication information is provided, then the system.user entity instance will contain the information of the authenticated user.
Additionally, BAARS endpoints can accept authentication both via Basic authentication and OpenID Connect authentication (but only one authentication type for a given request):
- in order to accept Basic authentication, an authentication provider which can authenticate based on username and password must be added to the authentication provider chain (eg. in-memory, ldap)
- in order to accept OpenID Connect authentication, an openid-connect authentication provider must be added to the authentication provider chain
In following example the authentication provider chain contains an in-memory authentication provider which reads users,passwords and roles from a users.properties file and an openid-connect authentication provider.
# username/password based authentication provider blueriq.security.auth-providers.memory.type=in-memory blueriq.security.auth-providers.users.location=aquima://users.properties # OpenID Connect authentication provider blueriq.security.auth-providers.oidc.type=openid-connect # both authentication providers are added to the chain blueriq.security.auth-providers-chain=memory,oidc
The order of the providers in the chain is not important is this case, since they are incompatible with eachother. The "memory" provider is unable to authenticate based on tokens, and the "oidc" provider is unable to authenticate based on username and password.
Note that if authentication information is provided, either as an Authorization: Basic or an Authorization: Bearer header, the information must be valid (must have a valid format for the authentication type and the provided credentials must be valid as well). This rule applies even if the endpoint is not secured.
Overview
Content Tools