-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2.8.0] OpenID connect user fails #516
Comments
The same will happens using mica2 and agate. |
Hi, which version of Keycloak do you have? (I cannot reproduce but maybe my keycloak is not recent enough) |
Hi @ymarcon we use 22.0.1. Other OpenID applications will work. |
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? |
Were you able to compare? without your feedback it is not possible to move on this issue. |
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. |
This will be very strange because agate will control the groups. |
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. |
It looks like you don't understand the problem right. |
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:
Note that the UserInfo content will depend on the ID provider configuration (keycloak) and the requested "Scope" |
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. |
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. |
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. |
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:
Then signin via OIDC is successful when:
|
Yes and point 1 and 2 are setup by us. When it helps, I can send you an video what will exact happens. |
Yes send me a video. |
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:
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
Log opal
The text was updated successfully, but these errors were encountered: