Authentication
Tasklist provides two ways to authenticate:
- User information stored in Elasticsearch
- Identity Authentication and Authorization
By default, user storage in Elasticsearch is enabled.
User in Elasticsearch​
In this mode, the user authenticates with a username and password stored in Elasticsearch.
The userId, password, and roles for one user may be set in application.yml:
camunda.tasklist:
userId: aUser
password: aPassword
roles:
- OWNER
- OPERATOR
On Tasklist startup, the user is created if they did not exist before.
By default, three users are created:
- Role
OWNER
with userId/displayName/passworddemo
/demo
/demo
. - Role
USER
with userId/displayName/passwordview
/view
/view
. - Role
OPERATOR
with userId/displayName/passwordact
/act
/act
/.
More users can be added directly to Elasticsearch, to the index tasklist-user-<version>_
. The password must be encoded with a strong BCrypt hashing function.
Identity​
Identity provides authentication and authorization functionality along with user management.
Enable Identity​
Identity can only be enabled by setting the Spring profile: identity-auth
.
See the following example:
export SPRING_PROFILES_ACTIVE=identity-auth
Configure Identity​
Identity requires the following parameters:
Parameter name | Description | Example value |
---|---|---|
camunda.tasklist.identity.issuerUrl | URL of issuer (Identity) | http://localhost:18080/auth/realms/camunda-platform |
camunda.tasklist.identity.issuerBackendUrl | Backend URL of issuer (Identity) | http://localhost:18080/auth/realms/camunda-platform |
camunda.tasklist.identity.clientId | Similar to a username for the application | tasklist |
camunda.tasklist.identity.clientSecret | Similar to a password for the application | XALaRPl...s7dL7 |
camunda.tasklist.identity.audience | Audience for Tasklist | tasklist-api |
spring.security.oauth2.resourceserver.jwt.issueruri | Token issuer URI | http://localhost:18080/auth/realms/camunda-platform |
spring.security.oauth2.resourceserver.jwt.jwkseturi | Complete URI to get public keys for JWT validation | http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/certs |
Use Identity JWT token to access Tasklist API​
Tasklist provides a GraphQL API under the endpoint /graphql
. Clients can access this API using a JWT access token in an authorization header Authorization: Bearer <JWT>
.
Be aware a JWT token is intended to be used for M2M communication and is therefore issued for the relevant application, not for the user.
Example:
- Add an application in Identity.
- Add permissions to an application for Tasklist API.
- Obtain a token to access the GraphQL API.
You will need:
client_id
andclient_secret
from Identity application you created.- URL of the authorization server will look like:
http://<keycloak_host>:<port>/auth/realms/camunda-platform/protocol/openid-connect/token
, where host and port reference Keycloak URL (e.g.localhost:18080
).
curl --location --request POST 'http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=<client id>' \
--data-urlencode 'client_secret=<secret>' \
--data-urlencode 'grant_type=client_credentials'
You will get something like the following:
{
"access_token": "eyJhbG...",
"expires_in": 300,
"refresh_expires_in": 0,
"token_type": "Bearer",
"not-before-policy": 0
}
Take the access_token
value from the response object and store it as your token.
- Send the token as an authorization header in each request. In this case, request all tasks.
curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer <TOKEN>" -d '{"query": "{tasks(query:{}){id name}}"}' http://localhost:8080/graphql