CODEWITHSUNDEEP
camunda
hsingh
hsingh

Reputation: 681

Camunda Authorization with Spring Security and JWT

I am using the camunda spring-boot-starter and running the embedded camunda engine.

For Authentication, we are using a JWT token and the user information exists in an outside database. From Camunda docs, what I understood is that, for Camunda Authorization like assigning A User Task to a user, will totally depend on the Camunda Database.

How should I use an outside user authenticated with an external system, for the Authorization purpose in the Camunda? Should I create a copy of the authenticated user in the Camunda Database?

Upvotes: 2

Views: 3070

Answers (1)

rob2universe
rob2universe

Reputation: 7628

As part of the authentication you can also tell Camunda which groups/roles the user belongs to. For instance as shown in this generic simple Spring Security example: https://github.com/camunda-consulting/code/tree/master/snippets/springboot-security-sso specifically: https://github.com/camunda-consulting/code/blob/4a609b375c6564838e85a1bde7d70e5a9951ab64/snippets/springboot-security-sso/src/main/java/com/camunda/demo/filter/webapp/SpringSecurityAuthenticationProvider.java#L35

Another mechanism uses a custom identity provider (read-only or writable) as explained here: https://docs.camunda.org/manual/latest/user-guide/process-engine/identity-service/#custom-whitelist-for-user-group-and-tenant-ids

It is correct that the default implementation is the database identity service, which uses the engine database for managing users and groups. However, this is only the case if no alternative identity service implementation is provided. Camunda also provides an LDAP identity service for an LDAP-based user/group repository and you can of course implement your own.

Once you have an authenticated user and user group information for the user, the detailed functional permissions are linked to these groups as shown here: https://docs.camunda.org/manual/latest/webapps/admin/authorization-management/

You don't have to manage users in Camunda and or to sync with another system. If user's authorizations (groups, roles) should be fetched from another system, then use the SPI mentioned above. Either way you don't need to create the users in the Camunda DB. When a request comes in you may set the user and its roles on the IdentityService. In your subsequent API usage the user id and the authorization will be considered (if auth is enabled). If authorizations are disabled, then you only need the user id, not the groups/roles. If you want to provide neither and handle everything in your custom code, then you can just complete task without the user's Id (but won't have the user info in the audit information).

Upvotes: 2

Related Questions