You are viewing the documentation for Blueriq 14. 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 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 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.


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.



  • No labels

Didn't find the answer you were looking for? Try the advanced search!