OpenID Connect and Oauth 2.0 support

[CanerPatir]

Hi,

For the rest API, openId and OAuth support would be better instead of basic auth. I want to contribute by supplying OpenID and OAuth support. However, I am familiar with java as much as dot net developer. Is there any suggestion to hook into current authentication logic? Maybe we can implement OpenID server capabilities for IDM app then consume the API through using token which comes from identity provider which is located in the IDM. I am waiting for your comments to understand authentication flow better.

[tijsrademakers]

Hi,

Interesting idea and great that you are looking at contributing this to the Flowable community. The starting would be the flowable-idm-engine and the flowable-ui-idm-app. By default they run against a relational database, but we also have support for LDAP for example, using the flowable-ldap and flowable-ldap-configurator modules. Let us know if you need more pointers.

Best regards,

Tijs

[CanerPatir]

Thank you for your interest. I will also review LDAP side and try to implement openID support.

[mattydebie]

Is there any progress on this?

[rasheedamir]

@tijsrademakers I wonder if you guys plan to implement it yourself?

[mattydebie]

@rasheedamir I have a work-in-progress Pull Request open to implement this. Maybe you can check that out. It needs some improvement I think, but using that, I was able to use KeyCloak (OpenID-Connect) with flowable.

[VeridianDynamics]

I did some experimentation and I was able to somewhat successfully set up Spring Security to use OIDC/OAuth 2.0 as the authentication provider. This means that I can log in as the external user and can provide Flowable with the user's details received from the authentication provider. However, I ran into an interesting problem which might really complicate things. Unlike LDAP, OIDC/OAuth 2.0 standard does not provide information about user groups (apart from certain special implementations).

Flowable, however, seems to be using the concept of user groups to figure out which users are candidates for various tasks and so on. Normally, this information is provided by Flowable IDM, but what do we do if we cannot obtain it from the external authentication provider?

Hence, I could use some architectural advice. Can we somehow sidestep this problem? If not, what would be a good solution? One possibility could be making a simplified IDM which would store the mapping between users and groups only, but this could be a lot of work.