[2.8.0] OpenID connect user fails

[tuxmaster5000]

Describe the bug When the user are in an realm which use keycloak and OpenIDC as the back end,the login from opal fails.

To Reproduce Steps to reproduce the behavior:

1. Create an Realm which will use an OpenIDC service
2. Add an user to the realm
3. Try to login from an opal instance which is connected to agate.
4. The login fails

Expected behavior That the user can log in.

Additional context When the user is an an local ream or in an LDAP realm then it will work.

Log agate

==> /var/log/agate/spring.log <== 2023-07-06 14:54:44.393 INFO 1514 --- [qtp1163336956-137] o.o.a.web.rest.ticket.TicketsResource : Authentication failure of user 'foo' at ip: 'OpalIP': No account information found for authentication token [org.apache.shiro.authc.UsernamePasswordToken - foo, rememberMe=false] by this Authenticator instance. Please check that it is configured correctly.

==> /var/log/agate/agate.log <== 2023-07-06 14:54:44,393 INFO org.obiba.agate.web.rest.ticket.TicketsResource - Authentication failure of user 'foo' at ip: 'OpalIP': No account information found for authentication token [org.apache.shiro.authc.UsernamePasswordToken - foo, rememberMe=false] by this Authenticator instance. Please check that it is configured correctly.

==> /var/log/agate/rest.log <== {"@timestamp":"2023-07-06T14:54:44.394+02:00","@version":"1","message":"/tickets queryParams:{rememberMe: [false]}","logger_name":"org.obiba.agate.web.rest.security.AuditInterceptor","thread_name":"qtp1163336956-137","level":"WARN","level_value":30000,"method":"POST","ip":"OpalIP","username":"Anonymous","status":"403"}

Log opal

==> /var/log/opal/opal.log <== 2023-07-06 14:54:08,331 [qtp2087831689-35] WARN org.obiba.shiro.web.filter.AbstractAuthenticationExecutor - Login failed for user 'foo' [5] 2023-07-06 14:54:08,331 [qtp2087831689-35] INFO org.obiba.opal.web.security.AuthenticationResource - Authentication failure of user 'foo' at ip: '[0:0:0:0:0:0:0:1]': No account information found for authent ication token [org.apache.shiro.authc.UsernamePasswordToken - foo, rememberMe=false] by this Authenticator instance. Please check that it is configured correctly.

==> /var/log/opal/rest.log <== {"@timestamp":"2023-07-06T14:54:08.331+02:00","@version":"1","message":"/auth/sessions","logger_name":"org.obiba.opal.web.security.AuditInterceptor","thread_name":"qtp2087831689-35","level":"WARN","level_value": 30000,"method":"POST","ip":"ClientIP","username":"Unknown","status":"403"}

[tuxmaster5000]

The same will happens using mica2 and agate.

[ymarcon]

Hi, which version of Keycloak do you have? (I cannot reproduce but maybe my keycloak is not recent enough)

[tuxmaster5000]

Hi @ymarcon we use 22.0.1. Other OpenID applications will work.

[ymarcon]

I have setup a local keycloak (latest version) and a local agate (+mica and opal) and it works. I am sharing with you the corresponding agate's realm. Could you check for differences with what you have?

Agate-keycloak.pdf

[ymarcon]

Were you able to compare? without your feedback it is not possible to move on this issue.

[tuxmaster5000]

What do you mean? Here the setting from the IDP config on our site:

[ymarcon]

You are not assigning the users of this realm a group, therefore these users are not considered as being mica users. You must specify in the field "Groups" at least a group name that is allowed to login in the Mica application (most probably called "mica-user").

Also you should specify the account login url so that user can manage its account in keycloak.

See the PDF file attached in this previous comment for comparision.

[tuxmaster5000]

This will be very strange because agate will control the groups. I have the user in agate with its groups and OpenID as the real. This will work, when the user direct log into agate. But it will fail's when the user comes over opal/mica. And it will works, when using LDAP as the ream. Only when OpenID are the real, opal/mica don't find the user in agate.

[ymarcon]

It is not strange at all: it is not because you declare a realm in agate that its users can access all the applications declared in agate. And grouping users does not grant them permissions. These are defined in each application.

[tuxmaster5000]

It looks like you don't understand the problem right. The OpenID login in agate itself will works. But when Opal or Mica use Agate for the central user management then it will fails. Agate don't find the user in it's database. But the user exits, because I can change the realm for the user (for example to LDAP). After that Agate will authorize the user against LDAP. But set the user realm to OpenID, then Agate don't find the user when Opal/Mica ask Agate for authorization.

[ymarcon]

This issue is about OIDC/Keycloak, not LDAP. Have you configured the "Groups" field in the Realm settings as I recommended ?

By setting the Groups, all the users from the OIDC realm will be member of this group. If you want to be more specific with the users, it is possible by setting a UserInfo mapping rule:

• either with "Groups by claim" which maps directly a UserInfo claim to a Agate group name
• or with "Groups by JS" which is a small chunk of javascript code that will extract/convert Agate group names from the UserInfo object

Note that the UserInfo content will depend on the ID provider configuration (keycloak) and the requested "Scope"

[tuxmaster5000]

I don't think, this are the problem, because direct login into agate will work. Also with with the groups. It only fails, when oapl/mica try's to use agate.

[ymarcon]

Agate is not an "Agate application" and therefore cannot be compared with Opal/Mica which are "Agate applications". If login works in Agate works, that means user authentication works. But Agate won't let user login through Opal/Mica if s/he is not authorized to.

[tuxmaster5000]

And this will be the problem. Agate only try's to authorize the user if there are LDAP or local users. When the realm type for the user points to OpenID, agate simple report to Opal/Mica "User unknown" instant to authorize the user against the OpenID server.

[ymarcon]

That is not correct: a local user who has not been granted access to an Agate application (e.g. mica), or who does not belong to a group having access to an Agate application, will not be authorized to sign-in this Agate application. From the mica application point of view, this user is unknown because s/he is not a member of the "mica application users".

The OIDC realm usage scenario is the following:

• from mica sign-up page, the user signs up with the declared OIDC provider (keycloak)
• if the OIDC authentication is successful, the Mica signup form is prefilled with the personal information that could be retrieved from the OIDC provider
• user submits the sign up form, and a new user is created in Agate, associated to the OIDC realm and with the group membership applied according to the OIDC config described in the above comments
• optional: if no automated membership is configured in the OIDC realm, an Agate administrator must grant manually access to the mica application (assign a group membership or grant direct access)
• then user can sign in from the mica signin page, through the OIDC realm

Then signin via OIDC is successful when:

1. the user exists as a Agate user linked to the corresponding OIDC realm: this agate user was either created directly by the admin or by the above signup process
2. the user has been granted access to the destination application (mica), either automatically at signup or manually by the agate admin

[tuxmaster5000]

Yes and point 1 and 2 are setup by us. When it helps, I can send you an video what will exact happens.

[ymarcon]

Yes send me a video.