Page History
...
| Info |
|---|
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 model 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:
...
| Code Block |
|---|
# 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.useruse-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.
...
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
...
| Code Block |
|---|
# 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 in this case, since they are incompatible with eachothereach other. The "memory" provider is unable to authenticate based on tokens, and the "oidc" provider is unable to authenticate based on username and password.
...
Overview
Content Tools