6. BAARS

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

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 5. AQ_RestServiceClient 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.use-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 two authentication providers:

• 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 in this case, since they are incompatible with each other. The "memory" provider is unable to authenticate based on tokens, and the "oidc" provider is unable to authenticate based on username and password.