OIDC SSO authentication

[tomvda]

This PR should be the followup of PR #1447 as proposed there

It introduces some interfaces and abstract classes for several OIDC authentication providers and includes an implementation for Keycloak

Changes/improvements compared to the previous PR:

• Starting from current master
• Cleanup with more configurable properties and better error handling (if certain claims are not available for ex.)
• Other OIDC handlers can be implemented in custom libraries like we did, extending this ones

The OIDC implementation uses an OpenID Connect implementation on Spring Security. This was previously also already the case.

Additional properties in application.properties:

• flowable.sso.provider=keycloak -> enable using the KeycloakSsoHandler
• flowable.sso.keycloak.url.auth -> authorization endpoint
• flowable.sso.keycloak.url.token -> token endpoint
• flowable.sso.keycloak.url.info -> user info endpoint
• flowable.sso.keycloak.cient-id
• flowable.sso.keycloak.cient-secret
• flowable.sso.keycloak.scope -> the oauth scope needed to receive all necessary claims about a user, no scope will be requested if this property is missing
• flowable.sso.keycloak.userinfo.tenant -> the tenant attribute or claim for the user coming from Keycloak
• flowable.sso.keycloak.userinfo.client_roles -> the privileges claim for the user coming from Keycloak

In your realm on Keycloak you should configure an additional client using following settings

• access type -> confidential
• standard flow enabled
• implicit flow disabled
• enter the valid redirect url -> the path for the KeycloakSsoHandler is (ex. https://your.flowable.instance/flowable-idm/sso/return)
• add client roles which can be assigned to users
  • access-idm
  • access-admin
  • access-modeler
  • access-task
  • access-rest
• add extra mappers
  • tenant -> an optional claim of JSON type string, available in userinfo and access token
  • privileges -> an optional multi-valued claim of JSON type string, containing the assigned client roles listed above, also available in userinfo and access token

The KeycloakSsoHandler will register new users in flowable-idm if they don't exist yet and update existing ones. Currently the handler gets all info from the userinfo endpoint, also tenant and privileges, but this should also be read from the JWT access token if available there; we'll improve this soon.

Tenant and privileges claims are optional now, but:

• if no privileges, you'll need to set the privileges manually in flowabe-idm for each user or they wont have any access
• if no tenant, the user will be able to access all tenants (default behavior in flowable)

Future improvements:

• also allow JWT token to read claims
• use OIDC discovery via well-known url
• allow granting access to multiple tenants -> see inuits/flowable-engine tenant-mapping branch

[dbmalkovsky]

Please add missing license headers to the files; thanks.

[tijsrademakers]

@tomvda thanks for the new PR. This looks really good. We will do some testing with the PR and come back with final feedback / merge it.

[hberrayana]

Thank you @tomvda I was waiting for this feature.
So currently I think that only Keycloak is supported as SSO server right?
I haven't tested it bit went through the code only. My question is why don't we support generic OIDC/OAuth2 providers by configuring redirect, token urls ? Is it related to roles mapping ?

[tomvda]

@hberrayana, in fact it's certainly not only Keycloak that is supported, but it is the only one well tested. We could consider to refactor to OIDC, but it should already work with other OIDC IDPs as well. Some IDPs have there own specific requirements on top of OIDC, but it that case you could just extend the Keycloak/OIDC one and implement the differences.
There are indeed some extras in OIDC which are not in OAuth, so a normal OAuth server might not be enough; roles mapping and id token is one yes.
Still you could easily implement an OAuth version by implementing the SSOHandler and put it in your own library which will work on top of the upstream Flowable release ... if this PR gets merged of course :)

[tijsrademakers]

Hi @tomvda ,

Sorry for the long overdue response to the PR. We have been discussing the implementation of the PR in the Flowable dev team and we think it's a great addition to have additional authentication methods in the Flowable UI applications.
Currently there's some complications due to the way the Flowable IDM application is currently implemented to provide a kind of SSO functionality for the Flowable UI applications. Looking back we think this choice complicates the setup of the Flowable UI applications a lot and the only benefit is that you can switch between the Flowable Task and for example the Modeler application without having to login again.
What we want to propose is to remove the need to use the Flowable IDM application as the SSO component, so that every application can have its own way of authentication and autorisation. Then we could have this PR implemented for every application without having a need to store the user information in the Flowable database anymore and the external identity provider is the sole owner of the user and group information. We are currently planning this as part of the work we want to do in July timeframe.
Any feedback is welcome

Best regards

[tomvda]

@tijsrademakers,

The problem was infact the high dependency on the current flowable-idm from the different apps; you could maybe avoid the cookie based authentication via flowable-idm, but flowable-idm is also used as user and groups resources in for instance task assignments.
So removing flowable-idm and trying to avoid storing users and groups in flowable apps, would also mean that you need to provide alternative resources to retrieve this user and group information.
We are not really using those resources and we would certainly be fully in favor of removing all dependencies on flowable-idm, but this has a huge impact and us introducing these changes would certainly have resulted in a rejection of our work I'm afraid. So this is why we chose to continue with flowable-idm.

Many IDP's have API endpoints to retrieve user and group information. So it would certainly be viable to have multiple implementations to retrieve user and group information from remote services.

Looking forward to it!

kr,
Tom

[filiphr]

Closing this PR since it has been superseded by #2531. We did what @tijsrademakers said in #2281 (comment).

We are using Spring Security OAuth2, which means that you can login with Keycloak, Google, Okta etc. Basically any OAuth2 provider out there.

Additionally we have added a rudimentary IdentityService (Only for the Example UI Apps) that uses the Keycloak REST API to query for users and groups.

We have a blog post lined up where we explained these changes.

Please try out what is on master and give us feedback.