Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before

On Wed, 25 Sep 2019 at 10:22, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 25. 09. 19 8:37, Stian Thorgersen wrote: > Adding config options on a single mappers is not really a great > solution. We need to make sure there is a consistent approach > throughout. We probably don't have consistent and predictable > behaviour today, but I would rather not make it worse by > introducing random config options on mappers. > > Main question is if this should be controlled on individual > mappers or if it should mainly be a config on the identity provider. > > Having the config on the identity provider would make more sense > as it would be simpler to configure and it would avoid corner cases. I am not very sure about the single option at Idp level. IMO in many cases, the requirement is to have "mixed" mode. For example customer wants that profile info (firstName, lastName, email etc) are managed from Idp and always want to use latest stuff from Idp during every login, but the role mappings should be managed entirely by Keycloak. Or possibly roles are just initially imported from Idp, but then managed by Keycloak etc. Some fine-grained control is needed in option 2 I listed below, but it needs to be designed properly and made consistent, not just a bunch of random options on individual mappers. > > There's probably at least 3 different modes for identity > brokering that should be supported: > > 1) Import only - User is only imported if it doesn't exist. If > user already exists nothing is updated. > 2) Sync - Allow changes to the user within Keycloak, but also > sync changes from external IdP > 3) External - Do not allow any changes to the user within > Keycloak as the user should be fully managed from the external IdP > > Option 1 is trivial. > > Option 2 can be very complicated. Take the example of the > hardcoded role for instance. User first logs in, the role is > added. An admin then removes the role from the user. User logs in > again and the role is re-added. Same example can be applied to > last name for instance. User logs in. 6 months later the user > changes the last name in Keycloak account console, but then next > day when they re-login the last name is changed back. > > Option 3 is relatively trivial, but would need some tweaks within > Keycloak. A user that is fully externally managed should not be > able to use Keycloak account console and should be view-only in > the admin console. 1 is what we already have. 2 is what we will have if we add the switch to the mapper or Idp. IMO this won't be complicated to implement, but I agree that behaviour is quite tricky... It is maybe fine for many deployments, but it will need to be clearly documented that update on Keycloak side will be lost upon next login to Idp. With sync you expect something smarter than just having individual mappers overwrite local changes. It is not very elegant to allow a user to change their first name in the KC account console, if it will just be overwritten next login. Same it is not very elegant to allow admins removing roles that will just be added again on next login. 3 will be more complicated to implement and will require changes to SPI of IdentityProviderMapper. For example we may need IdentityProviderMappers to return UserModel, so that they are able to return proxy object (subclass of UserModelDelegate) similarly like UserStorage providers do. This will allow lots of flexibility and mixed mode (EG. support for profile data to be managed by Idp and being read-only in Keycloak, but role memberships to be managed by Keycloak and hence editable from Keycloak). Problem is, that there are lots of corner-cases with that approach. Especially user can be linked to multiple Identity providers, but the UserModel proxy object should be always the same... You've absolutely lost me here. In option 3 a user is fully managed externally and no local changes is permitted.

Another point is, that we have the use-case from many people, that Idp user should be "temporary" in Keycloak (EG. read-only and not written to Keycloak DB at all) and also the requirement to register the Idp user to specified userStorage provider. If we do any major change in the IdentityProviderMappers and related Keycloak codebase, we should probably address this use-case as well at the same time IMO. Agree, supporting temporary users is mostly about adding support for option 3 and having some temporary way of storing users (Infinispan I guess). Marek > > > > > > On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > Makes sense to me. From me +1 for this. > > Marek > > On 20. 09. 19 15:57, Schuster Sebastian (INST-CSS/BSV-OS2) wrote: > > I guess the point was just to add a configuration flag to > the mapper enabling the update on existing users. > > If that flag is not there or set to false, the old behavior > stays. > > > > Best regards, > > Sebastian > > > > > > Mit freundlichen Grüßen / Best regards > > > > Dr.-Ing. Sebastian Schuster > > > > Open Source Services (INST-CSS/BSV-OS2) > > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 > Berlin | GERMANY | www.bosch-si.com <http://www.bosch-si.com> > > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax > +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com > <mailto:Sebastian.Schuster@bosch-si.com> > > > > Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; > HRB 148411 B > > Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; > Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. > Aleksandar Mitrovic > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: keycloak-dev-bounces(a)lists.jboss.org > <mailto:keycloak-dev-bounces@lists.jboss.org> > <keycloak-dev-bounces(a)lists.jboss.org > <mailto:keycloak-dev-bounces@lists.jboss.org>> Im Auftrag von > Stian Thorgersen > > Gesendet: Freitag, 20. September 2019 15:25 > > An: EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) > <external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com>> > > Cc: keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > Betreff: Re: [keycloak-dev] A newly added Hardcoded Role > mapper ignores users that have already logged in before > > > > I'm afraid you've lost me on the last one as I'm not > following ;) > > > > On Thu, 19 Sep 2019 at 16:17, EXTERNAL Thiele Frank (TNG, > INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com>> wrote: > > > >> Hi, > >> > >> > >> > >> What if I implement a newer version of the Hardcoded Role > mapper that > >> has a (optional, as configuration migration case) flag to > activate > >> update handling. So when the flag is set to false or not > set at all > >> (migration case), then behavior is as of today. If the > flag is set, > >> the import and update functions behave the same way. > >> > >> > >> > >> > >> > >> Mit freundlichen Grüßen / Best regards > >> > >> > >> *Frank Thiele * > >> Open Source Services 2 - Product Group Customer Success > Services > >> (INST-CSS/BSV-OS2) > >> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 > Berlin | > >> GERMANY | www.bosch-si.com <http://www.bosch-si.com> Tel. > +49 30 726112-0 | Fax +49 30 > >> 726112-100 | external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com> > >> > >> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; > HRB 148411 > >> B > >> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; > Geschäftsführung: Dr. > >> Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic > >> > >> > >> > >> *Von:* Stian Thorgersen <sthorger(a)redhat.com > <mailto:sthorger@redhat.com>> > >> *Gesendet:* Donnerstag, 19. September 2019 13:51 > >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < > >> external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com>> > >> *Cc:* keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role > mapper > >> ignores users that have already logged in before > >> > >> > >> > >> If memory serves me correctly this was on purpose where > the thinking 5 > >> years ago was that users would be imported on first login, > then > >> managed from Keycloak after that. That is not always the > case though > >> and we should have some way of controlling if users updated on > >> subsequent logins and perhaps also be able to fine-tune > what is updated. > >> > >> > >> > >> On Thu, 19 Sep 2019 at 13:21, EXTERNAL Thiele Frank (TNG, > >> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com>> wrote: > >> > >> Hello, > >> > >> > >> > >> In our project, we use the "Hardcoded role" mapper within > a configured > >> Identity Provider (also a Keycloak instance, in our case > the same but > >> a different realm) to describe that each user logging in > via Keycloak > >> shall be given a certain role. > >> > >> This works perfectly if the mapper is configured before > the first > >> login of the user. The configured role is granted to the > (cloned) user > >> when he logs in the first time via Keycloak. > >> > >> But when another "Hardcoded role" mapper is added to > configure another > >> role, then the user is not given the other role when he > logs in. Only > >> new users logging in the first time get both roles assigned. > >> > >> > >> > >> Is this on purpose or a bug? > >> > >> > >> > >> Mit freundlichen Grüßen / Best regards > >> > >> > >> > >> Frank Thiele > >> > >> > >> > >> Open Source Services 2 - Product Group Customer Success > Services > >> (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH | > Ullsteinstr. 128 > >> | > >> 12109 Berlin | GERMANY | www.bosch-si.com > <http://www.bosch-si.com><http://www.bosch-si.com< > >> http://www.bosch-si.com%3chttp:/www.bosch-si.com > <http://www.bosch-si.com>>> > >> > >> external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com><mailto: > >> external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com><mailto: > >> external.Frank.Thiele(a)bosch-si.com > <mailto:external.Frank.Thiele@bosch-si.com>% > >> 3cmailto:external.Frank.Thiele@bosch-si.com > <mailto:3cmailto%3Aexternal.Frank.Thiele@bosch-si.com>>> > >> > >> > >> > >> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; > HRB 148411 > >> B > >> > >> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; > Geschäftsführung: Dr. > >> Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >