Transparent SSO

Hi, we have been working on the usage of a SSO extension, allowing a front-end that has users authenticated at an identity provider known to a moqui backend, to transparently accessing that moqui backend with the granted permissions as defined by the identity provider.

These requires changes at both, the moqui-sso component and at the Framework.

One aspect that could be improved limiting the moqui session duration.

The changes are in following pull requests:

2 Likes

Could you please explain it with a use case example?

1 Like

An example would be following:
A front-end system authenticates a user with credentials stored in a Keycloak server, interacts with the user and eventually needs to access a moqui REST API. The authentication data is stored in a JWT generated by the Keycloak server, which includes an access token.

The moqui instance is previously configured with data about the Keycloak server, stored in the moqui.security.sso.AuthFlow entity. This includes credentials for moqui to authenticate before the Keycloak server as a client, as well as mappings for userAccount fields and group memberships.

In order for moqui to authenticate the user, the front-end sends a header named “sso_access_token”, and optionally another header named sso_auth_flow with the identifier of the AuthFlow. With this data, moqui checks the validity of the Keycloak session and synchronizes UserAccount and GroupMembership data, logs in the user and serves the request.

This works seamlessly for the user, without the need to type in new (or same) credentials in order to gain access to the moqui back-end.

2 Likes

I would love to see a demo of this on a Moqui call if you’re up for it

I know of 3 companies that have built a keycloak integration to some degree. It’s probably worth coming together and sharing effort on keycloak integrations.