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%3chttp:/www.bosch-si.com>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com% 3cmailto: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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Donnerstag, 19. September 2019 13:51 *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < external.Frank.Thiele(a)bosch-si.com&gt; *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com% 3cmailto: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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Donnerstag, 19. September 2019 13:51 *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < external.Frank.Thiele(a)bosch-si.com&gt; *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com% 3cmailto: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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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 < keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >> 726112-100 | external.Frank.Thiele(a)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&gt; >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >> external.Frank.Thiele(a)bosch-si.com&gt; >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com% >> 3cmailto: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 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi, That is an interesting point. I checked some mappers: - AttributeToRoleMapper handles the update like the import with the exception that in case of an update, the role is deleted if the attribute is no longer present (I call this for now inverted logic). - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle an update with the inverted logic only – so they don’t set but only delete the role. - HardcodeRoleMapper fully ignores updates whereas it could at least do it the same way as AttributeToRoleMapper. - UserAttributeMapper is even more complex… So the currently used IdentityProviderMapper implementations are very inconsistent and hopefully documented and understood well for and by the end users.

All I am saying is that it will become a breaking change to globally define this behavior as there are nowadays several, conflicting modes implemented. Due to that I would like to emphasize that the flag introduction (“handleUpdateToo”) still seems as the solution with the lowest friction.

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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Mittwoch, 25. September 2019 08:38 *An:* Marek Posolda <mposolda(a)redhat.com&gt; *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; keycloak-dev(a)lists.jboss.org *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before 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. 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. On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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 < keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >> 726112-100 | external.Frank.Thiele(a)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&gt; >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >> external.Frank.Thiele(a)bosch-si.com&gt; >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com% >> 3cmailto: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 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

https://issues.jboss.org/browse/KEYCLOAK-8690 Adding to my point that we need a consistent solution/strategy for all mappers. On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, > INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: > >> Hi, >> >> >> >> That is an interesting point. I checked some mappers: >> >> - AttributeToRoleMapper handles the update like the import with >> the exception that in case of an update, the role is deleted if the >> attribute is no longer present (I call this for now inverted logic). >> >> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle >> an update with the inverted logic only – so they don’t set but only delete >> the role. >> >> - HardcodeRoleMapper fully ignores updates whereas it could at >> least do it the same way as AttributeToRoleMapper. >> >> - UserAttributeMapper is even more complex… >> >> So the currently used IdentityProviderMapper implementations are very >> inconsistent and hopefully documented and understood well for and by the >> end users. >> > > It is not documented and I doubt anyone can understand how it will > function. This is my concern when we have "random" things happening in each > mapper without an overall consistent plan. > > >> >> >> All I am saying is that it will become a breaking change to globally >> define this behavior as there are nowadays several, conflicting modes >> implemented. Due to that I would like to emphasize that the flag >> introduction (“handleUpdateToo”) still seems as the solution with the >> lowest friction. >> > > Adding a flag to an individual mapper is just a solution to your problem > and it doesn't address the wider issue. It is basically a work-around for > your use-case, and is introducing yet another behaviour on top of the > already inconsistent behaviour we have today. > > Of course we need anything new that is added to be able to match the > current behaviour, which will be more and more difficult the more random > switches and config options we have in mappers. So we really do need to > have a proper solution in thought out, then figure out how to address it. > > >> >> >> 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 >> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >> external.Frank.Thiele(a)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&gt; >> *Gesendet:* Mittwoch, 25. September 2019 08:38 >> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >> keycloak-dev(a)lists.jboss.org >> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >> ignores users that have already logged in before >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 >> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >> 726112-100 | Sebastian.Schuster(a)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 < >> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >> >> 726112-100 | external.Frank.Thiele(a)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&gt; >> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >> >> external.Frank.Thiele(a)bosch-si.com&gt; >> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >> >> >> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> >> external.Frank.Thiele(a)bosch-si.com% >> >> 3cmailto: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 >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>

Stian, et al: It took me a few minutes to read through the entire thread and your last remarks strike me as a good path forward. So +1 for that. The follow-on thought I have about this is that mapping, and therefore per mapper configuration, would best be done on a per realm/domain level. This would address the federation concerns, but it would also mean that there might be an LDAP mapper for the @firstDomain with a different configuration from an LDAP mapper for @secondDomain.

Proceeding along this path, if you have local admins of the Keycloak system, role, attribute and identity mapping, then they could be controlled separately from some realm/domain for which the Keycloak system has user responsibilities. This might necessitate a “local” option that points to the Keycloak internal data, which would give you four options - - Import - Owner - Force - Local This same method could also be utilized to resolve issues of collision of nominated privilege. I have seen cases in the past, with other systems, where privilege collisions occur because a userID exists in two systems, which each nominate a differing level of privilege and may utilize the same token names for a privilege, e.g., Attribute= fwAdmin / value= superAdmin.

Respectfully submitted, Martin On Sep 25, 2019, at 05:23 , Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: Thinking about this some more. I think all mappers for identity brokering should have an option to select sync-mode: * import - only update on first import * owner - if the idp is the owner of the user (the user has not been modified within KC, and only has a single IdP link) * force - always update The mappers that today has a behaviour that doesn't match one of the above could have an option "legacy". On the IdP config itself there should be a default sync-mode user for mappers that haven't explicitly set the sync-mode. The default value should be import. The next piece of the puzzle would be to prevent editing of values that shouldn't be possible to edit locally. For user attributes that should be driven by User Profile SPI, where it would be somehow possible to for example say don't allow editing this attribute if one of the following IdPs. I'm working on a design proposal for the User Profile SPI currently, so we can add that as a requirement there. The same feature could be used for User Federation providers. For roles it is a bit harder, but would be nice to somehow be able to flag what roles are managed by IdP/user-storage and which are not. Perhaps we could add some metadata to the role mapping for that. Would be great to start on a design proposal around this, so we can have it documented the way it should work. Once we have that and have agreed on the approach I don't mind having PRs for individual mappers merged as I appreciate the fact that for this case you want a solution for hardcoded role mapper quickly without having to do all of the work for all the other mappers. On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: https://issues.jboss.org/browse/KEYCLOAK-8690 Adding to my point that we need a consistent solution/strategy for all mappers. On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: Hi, That is an interesting point. I checked some mappers: - AttributeToRoleMapper handles the update like the import with the exception that in case of an update, the role is deleted if the attribute is no longer present (I call this for now inverted logic). - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle an update with the inverted logic only – so they don’t set but only delete the role. - HardcodeRoleMapper fully ignores updates whereas it could at least do it the same way as AttributeToRoleMapper. - UserAttributeMapper is even more complex… So the currently used IdentityProviderMapper implementations are very inconsistent and hopefully documented and understood well for and by the end users. It is not documented and I doubt anyone can understand how it will function. This is my concern when we have "random" things happening in each mapper without an overall consistent plan. All I am saying is that it will become a breaking change to globally define this behavior as there are nowadays several, conflicting modes implemented. Due to that I would like to emphasize that the flag introduction (“handleUpdateToo”) still seems as the solution with the lowest friction. Adding a flag to an individual mapper is just a solution to your problem and it doesn't address the wider issue. It is basically a work-around for your use-case, and is introducing yet another behaviour on top of the already inconsistent behaviour we have today. Of course we need anything new that is added to be able to match the current behaviour, which will be more and more difficult the more random switches and config options we have in mappers. So we really do need to have a proper solution in thought out, then figure out how to address it. 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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Mittwoch, 25. September 2019 08:38 *An:* Marek Posolda <mposolda(a)redhat.com&gt; *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; keycloak-dev(a)lists.jboss.org *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before 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. 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. On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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 < keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Donnerstag, 19. September 2019 13:51 *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < external.Frank.Thiele(a)bosch-si.com&gt; *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com&lt;mailto: external.Frank.Thiele(a)bosch-si.com% 3cmailto: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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Stian: LDAP would be my mail client’s idea of a spellcheck joke. It was familiar with LDAP but not with IdP, so it did me the “favor” of “correcting” the spelling “error" and I did not notice. > On Sep 27, 2019, at 03:50, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > > On Wed, 25 Sep 2019 at 20:35, Martin Maher <gentoo(a)penguindreams.us&gt; wrote: >> Stian, et al: >> >> It took me a few minutes to read through the entire thread and your last remarks strike me as a good path forward. So +1 for that. >> >> The follow-on thought I have about this is that mapping, and therefore per mapper configuration, would best be done on a per realm/domain level. This would address the federation concerns, but it would also mean that there might be an LDAP mapper for the @firstDomain with a different configuration from an LDAP mapper for @secondDomain. >> > For the record I was only talking about IdPs (identity brokering), not LDAP. For LDAP we have very fine-grained control already and it also supports read/write sync, with that regards it's quite a different problem. > > I think the configuration should be at the IdP level, with an option to override on individual mappers. Not sure why it would be a realm/domain level, or what you actually mean by that? What I mean by realm/domain is what I will call the “location qualifier” of the submitted userID, e.g., elwood(a)dev.somedomain.tld versus elwood(a)somedomain.tld versus elwood(a)someotherdomain.tld. Even if all three were handled by the same IdP, wouldn’t it be conceivable that differing requirements might applicable?

>> >> Proceeding along this path, if you have local admins of the Keycloak system, role, attribute and identity mapping, then they could be controlled separately from some realm/domain for which the Keycloak system has user responsibilities. This might necessitate a “local” option that points to the Keycloak internal data, which would give you four options - >> >> • Import >> • Owner >> • Force >> • Local >> >> This same method could also be utilized to resolve issues of collision of nominated privilege. I have seen cases in the past, with other systems, where privilege collisions occur because a userID exists in two systems, which each nominate a differing level of privilege and may utilize the same token names for a privilege, e.g., Attribute= fwAdmin / value= superAdmin. >> > I'm afraid you've lost me a little. Perhaps it's because I'm talking about external OIDC/SAML providers, while you are talking about LDAP? What I was trying articulate was the addition of a fourth option, “local”, to the proposed three “import”, “owner”, and “force”, which would permit the user to be defined only in the Keycloak server db. While this would not be particularly useful in IdP configurations, it would allow for a non-IdP situation, such as locally-defined administrators of the Keycloak system or other small scope use cases.

As for my final paragraph, I put it into the response in the wrong place. The thought was associated with the concept of mappers being able to be unique configured at the realm/domain level, and how that would lend itself to working out collisions of nominated privilege. Hope this helps, Martin > Respectfully submitted, > > Martin > >> On Sep 25, 2019, at 05:23 , Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >> Thinking about this some more. I think all mappers for identity brokering >> should have an option to select sync-mode: >> >> * import - only update on first import >> * owner - if the idp is the owner of the user (the user has not been >> modified within KC, and only has a single IdP link) >> * force - always update >> >> The mappers that today has a behaviour that doesn't match one of the above >> could have an option "legacy". >> >> On the IdP config itself there should be a default sync-mode user for >> mappers that haven't explicitly set the sync-mode. The default value should >> be import. >> >> The next piece of the puzzle would be to prevent editing of values that >> shouldn't be possible to edit locally. For user attributes that should be >> driven by User Profile SPI, where it would be somehow possible to for >> example say don't allow editing this attribute if one of the following >> IdPs. I'm working on a design proposal for the User Profile SPI currently, >> so we can add that as a requirement there. The same feature could be used >> for User Federation providers. For roles it is a bit harder, but would be >> nice to somehow be able to flag what roles are managed by IdP/user-storage >> and which are not. Perhaps we could add some metadata to the role mapping >> for that. >> >> Would be great to start on a design proposal around this, so we can have it >> documented the way it should work. Once we have that and have agreed on the >> approach I don't mind having PRs for individual mappers merged as I >> appreciate the fact that for this case you want a solution for hardcoded >> role mapper quickly without having to do all of the work for all the other >> mappers. >> >> On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >>> https://issues.jboss.org/browse/KEYCLOAK-8690 >>> >>> Adding to my point that we need a consistent solution/strategy for all >>> mappers. >>> >>> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> That is an interesting point. I checked some mappers: >>>>> >>>>> - AttributeToRoleMapper handles the update like the import with >>>>> the exception that in case of an update, the role is deleted if the >>>>> attribute is no longer present (I call this for now inverted logic). >>>>> >>>>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle >>>>> an update with the inverted logic only – so they don’t set but only delete >>>>> the role. >>>>> >>>>> - HardcodeRoleMapper fully ignores updates whereas it could at >>>>> least do it the same way as AttributeToRoleMapper. >>>>> >>>>> - UserAttributeMapper is even more complex… >>>>> >>>>> So the currently used IdentityProviderMapper implementations are very >>>>> inconsistent and hopefully documented and understood well for and by the >>>>> end users. >>>>> >>>> >>>> It is not documented and I doubt anyone can understand how it will >>>> function. This is my concern when we have "random" things happening in each >>>> mapper without an overall consistent plan. >>>> >>>> >>>>> >>>>> >>>>> All I am saying is that it will become a breaking change to globally >>>>> define this behavior as there are nowadays several, conflicting modes >>>>> implemented. Due to that I would like to emphasize that the flag >>>>> introduction (“handleUpdateToo”) still seems as the solution with the >>>>> lowest friction. >>>>> >>>> >>>> Adding a flag to an individual mapper is just a solution to your problem >>>> and it doesn't address the wider issue. It is basically a work-around for >>>> your use-case, and is introducing yet another behaviour on top of the >>>> already inconsistent behaviour we have today. >>>> >>>> Of course we need anything new that is added to be able to match the >>>> current behaviour, which will be more and more difficult the more random >>>> switches and config options we have in mappers. So we really do need to >>>> have a proper solution in thought out, then figure out how to address it. >>>> >>>> >>>>> >>>>> >>>>> 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 >>>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >>>>> external.Frank.Thiele(a)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&gt; >>>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >>>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >>>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >>>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >>>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >>>>> keycloak-dev(a)lists.jboss.org >>>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >>>>> ignores users that have already logged in before >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 >>>>>> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >>>>> 726112-100 | Sebastian.Schuster(a)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 < >>>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >>>>>> Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >>>>>>> 726112-100 | external.Frank.Thiele(a)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&gt; >>>>>>> *Gesendet:* Donnerstag, 19. September 2019 13:51 >>>>>>> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >>>>>>> external.Frank.Thiele(a)bosch-si.com&gt; >>>>>>> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >>>>>>> >>>>>>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>>>>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>>>>> external.Frank.Thiele(a)bosch-si.com% >>>>>>> 3cmailto: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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >

Stian: >> On Oct 2, 2019, at 04:40, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >> >> >> On Fri, 27 Sep 2019 at 20:05, Martin Maher <gentoo(a)penguindreams.us&gt; wrote: >> Stian: >> >> LDAP would be my mail client’s idea of a spellcheck joke. It was familiar with LDAP but not with IdP, so it did me the “favor” of “correcting” the spelling “error" and I did not notice. >> >> > On Sep 27, 2019, at 03:50, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> > >> > >> > >> > On Wed, 25 Sep 2019 at 20:35, Martin Maher <gentoo(a)penguindreams.us&gt; wrote: >> >> Stian, et al: >> >> >> >> It took me a few minutes to read through the entire thread and your last remarks strike me as a good path forward. So +1 for that. >> >> >> >> The follow-on thought I have about this is that mapping, and therefore per mapper configuration, would best be done on a per realm/domain level. This would address the federation concerns, but it would also mean that there might be an LDAP mapper for the @firstDomain with a different configuration from an LDAP mapper for @secondDomain. >> >> >> > For the record I was only talking about IdPs (identity brokering), not LDAP. For LDAP we have very fine-grained control already and it also supports read/write sync, with that regards it's quite a different problem. >> > >> > I think the configuration should be at the IdP level, with an option to override on individual mappers. Not sure why it would be a realm/domain level, or what you actually mean by that? >> >> What I mean by realm/domain is what I will call the “location qualifier” of the submitted userID, e.g., elwood(a)dev.somedomain.tld versus elwood(a)somedomain.tld versus elwood(a)someotherdomain.tld. Even if all three were handled by the same IdP, wouldn’t it be conceivable that differing requirements might applicable? > > I can imagine there would be such a case, but would suggest we start simple with a single option on the IdP, then consider something more advanced later. This is a reasonable approach. Walk before crawling and all. >> >> >> >> Proceeding along this path, if you have local admins of the Keycloak system, role, attribute and identity mapping, then they could be controlled separately from some realm/domain for which the Keycloak system has user responsibilities. This might necessitate a “local” option that points to the Keycloak internal data, which would give you four options - >> >> >> >> • Import >> >> • Owner >> >> • Force >> >> • Local >> >> >> >> This same method could also be utilized to resolve issues of collision of nominated privilege. I have seen cases in the past, with other systems, where privilege collisions occur because a userID exists in two systems, which each nominate a differing level of privilege and may utilize the same token names for a privilege, e.g., Attribute= fwAdmin / value= superAdmin. >> >> >> > I'm afraid you've lost me a little. Perhaps it's because I'm talking about external OIDC/SAML providers, while you are talking about LDAP? >> >> What I was trying articulate was the addition of a fourth option, “local”, to the proposed three “import”, “owner”, and “force”, which would permit the user to be defined only in the Keycloak server db. While this would not be particularly useful in IdP configurations, it would allow for a non-IdP situation, such as locally-defined administrators of the Keycloak system or other small scope use cases. > > Not sure I understand how that would apply to a config at the IdP level. Users managed fully within Keycloak would not be managed by an IdP at all, hence there's no need for such an option at the IdP level. Unless I'm missunderstanding you that is. The idea here is to prevent a user acquired from an IdP from potentially overriding a locally defined user. Now that I think about the situation, it might be more of a preference on Keycloak that prevents overwrite or modification of locally-managed users by user data acquired from an IdP. There is every possibility that this preference already exists, or that the outcome I am imagining is not possible.

>> As for my final paragraph, I put it into the response in the wrong place. The thought was associated with the concept of mappers being able to be unique configured at the realm/domain level, and how that would lend itself to working out collisions of nominated privilege. >> >> Hope this helps, >> >> Martin >> >> > Respectfully submitted, >> > >> > Martin >> > >> >> On Sep 25, 2019, at 05:23 , Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >> >> >> Thinking about this some more. I think all mappers for identity brokering >> >> should have an option to select sync-mode: >> >> >> >> * import - only update on first import >> >> * owner - if the idp is the owner of the user (the user has not been >> >> modified within KC, and only has a single IdP link) >> >> * force - always update >> >> >> >> The mappers that today has a behaviour that doesn't match one of the above >> >> could have an option "legacy". >> >> >> >> On the IdP config itself there should be a default sync-mode user for >> >> mappers that haven't explicitly set the sync-mode. The default value should >> >> be import. >> >> >> >> The next piece of the puzzle would be to prevent editing of values that >> >> shouldn't be possible to edit locally. For user attributes that should be >> >> driven by User Profile SPI, where it would be somehow possible to for >> >> example say don't allow editing this attribute if one of the following >> >> IdPs. I'm working on a design proposal for the User Profile SPI currently, >> >> so we can add that as a requirement there. The same feature could be used >> >> for User Federation providers. For roles it is a bit harder, but would be >> >> nice to somehow be able to flag what roles are managed by IdP/user-storage >> >> and which are not. Perhaps we could add some metadata to the role mapping >> >> for that. >> >> >> >> Would be great to start on a design proposal around this, so we can have it >> >> documented the way it should work. Once we have that and have agreed on the >> >> approach I don't mind having PRs for individual mappers merged as I >> >> appreciate the fact that for this case you want a solution for hardcoded >> >> role mapper quickly without having to do all of the work for all the other >> >> mappers. >> >> >> >> On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: >> >> >> >>> https://issues.jboss.org/browse/KEYCLOAK-8690 >> >>> >> >>> Adding to my point that we need a consistent solution/strategy for all >> >>> mappers. >> >>> >> >>> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com > >> >>> wrote: >> >>> >> >>>> >> >>>> >> >>>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >> >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> >> >>>>> That is an interesting point. I checked some mappers: >> >>>>> >> >>>>> - AttributeToRoleMapper handles the update like the import with >> >>>>> the exception that in case of an update, the role is deleted if the >> >>>>> attribute is no longer present (I call this for now inverted logic). >> >>>>> >> >>>>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle >> >>>>> an update with the inverted logic only – so they don’t set but only delete >> >>>>> the role. >> >>>>> >> >>>>> - HardcodeRoleMapper fully ignores updates whereas it could at >> >>>>> least do it the same way as AttributeToRoleMapper. >> >>>>> >> >>>>> - UserAttributeMapper is even more complex… >> >>>>> >> >>>>> So the currently used IdentityProviderMapper implementations are very >> >>>>> inconsistent and hopefully documented and understood well for and by the >> >>>>> end users. >> >>>>> >> >>>> >> >>>> It is not documented and I doubt anyone can understand how it will >> >>>> function. This is my concern when we have "random" things happening in each >> >>>> mapper without an overall consistent plan. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> All I am saying is that it will become a breaking change to globally >> >>>>> define this behavior as there are nowadays several, conflicting modes >> >>>>> implemented. Due to that I would like to emphasize that the flag >> >>>>> introduction (“handleUpdateToo”) still seems as the solution with the >> >>>>> lowest friction. >> >>>>> >> >>>> >> >>>> Adding a flag to an individual mapper is just a solution to your problem >> >>>> and it doesn't address the wider issue. It is basically a work-around for >> >>>> your use-case, and is introducing yet another behaviour on top of the >> >>>> already inconsistent behaviour we have today. >> >>>> >> >>>> Of course we need anything new that is added to be able to match the >> >>>> current behaviour, which will be more and more difficult the more random >> >>>> switches and config options we have in mappers. So we really do need to >> >>>> have a proper solution in thought out, then figure out how to address it. >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> 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 >> >>>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >> >>>>> external.Frank.Thiele(a)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&gt; >> >>>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >> >>>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >> >>>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >> >>>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >> >>>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >> >>>>> keycloak-dev(a)lists.jboss.org >> >>>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >> >>>>> ignores users that have already logged in before >> >>>>> >> >>>>> >> >>>>> >> >>>>> 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. >> >>>>> >> >>>>> >> >>>>> >> >>>>> 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. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 >> >>>>>> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >> >>>>> 726112-100 | Sebastian.Schuster(a)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 < >> >>>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >> >>>>>> Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >> >>>>>>> 726112-100 | external.Frank.Thiele(a)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&gt; >> >>>>>>> *Gesendet:* Donnerstag, 19. September 2019 13:51 >> >>>>>>> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >> >>>>>>> external.Frank.Thiele(a)bosch-si.com&gt; >> >>>>>>> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >> >>>>>>> >> >>>>>>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> >>>>>>> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> >>>>>>> external.Frank.Thiele(a)bosch-si.com% >> >>>>>>> 3cmailto: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 >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> keycloak-dev mailing list >> >>>>>>> keycloak-dev(a)lists.jboss.org >> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>>>> >> >>>>>>> >> >>>>>> _______________________________________________ >> >>>>>> keycloak-dev mailing list >> >>>>>> keycloak-dev(a)lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> keycloak-dev mailing list >> >>>>>> keycloak-dev(a)lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>> >> >>>>> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> >

On 25. 09. 19 14:23, Stian Thorgersen wrote: Thinking about this some more. I think all mappers for identity brokering should have an option to select sync-mode: * import - only update on first import * owner - if the idp is the owner of the user (the user has not been modified within KC, and only has a single IdP link) * force - always update The mappers that today has a behaviour that doesn't match one of the above could have an option "legacy". On the IdP config itself there should be a default sync-mode user for mappers that haven't explicitly set the sync-mode. The default value should be import. +1 for this part. With the small note that not all mapper implementations may need this option. For example UsernameTemplateMapper.

The next piece of the puzzle would be to prevent editing of values that shouldn't be possible to edit locally. For user attributes that should be driven by User Profile SPI, where it would be somehow possible to for example say don't allow editing this attribute if one of the following IdPs. I'm working on a design proposal for the User Profile SPI currently, so we can add that as a requirement there. The same feature could be used for User Federation providers. For roles it is a bit harder, but would be nice to somehow be able to flag what roles are managed by IdP/user-storage and which are not. Perhaps we could add some metadata to the role mapping for that. Yes, will be great to have this capability on User Profile SPI. I am not sure about metadata for role/group mappings. There will be some added complexity in that and not sure it deserves the benefits - also considering that role/group memberships is something, which is editable just by administrator and not by user himself in account console.

Regarding User Profile SPI, I can imagine that it will be nice to have the ability to automatically update the metadata/requirements based on some events? For example when we add support for "temporary" users registered through IDP, those users will be typically read-only. So I can imagine that when administrator creates IDP with temporary users, there will be an event, which will automatically add rules to User Profile SPI that all attributes of such user should be read-only. Similarly when you have read-only LDAP provider or SSSD provider, you may also want auto-created User Profile metadata specifying that users should be non-editable. I am not sure whether to count with this in the User Profile SPI design or not?

Marek Would be great to start on a design proposal around this, so we can have it documented the way it should work. Once we have that and have agreed on the approach I don't mind having PRs for individual mappers merged as I appreciate the fact that for this case you want a solution for hardcoded role mapper quickly without having to do all of the work for all the other mappers. On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > https://issues.jboss.org/browse/KEYCLOAK-8690 > > Adding to my point that we need a consistent solution/strategy for all > mappers. > > On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> >> >> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >> >>> Hi, >>> >>> >>> >>> That is an interesting point. I checked some mappers: >>> >>> - AttributeToRoleMapper handles the update like the import with >>> the exception that in case of an update, the role is deleted if the >>> attribute is no longer present (I call this for now inverted logic). >>> >>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle >>> an update with the inverted logic only – so they don’t set but only delete >>> the role. >>> >>> - HardcodeRoleMapper fully ignores updates whereas it could at >>> least do it the same way as AttributeToRoleMapper. >>> >>> - UserAttributeMapper is even more complex… >>> >>> So the currently used IdentityProviderMapper implementations are very >>> inconsistent and hopefully documented and understood well for and by the >>> end users. >>> >> >> It is not documented and I doubt anyone can understand how it will >> function. This is my concern when we have "random" things happening in each >> mapper without an overall consistent plan. >> >> >>> >>> >>> All I am saying is that it will become a breaking change to globally >>> define this behavior as there are nowadays several, conflicting modes >>> implemented. Due to that I would like to emphasize that the flag >>> introduction (“handleUpdateToo”) still seems as the solution with the >>> lowest friction. >>> >> >> Adding a flag to an individual mapper is just a solution to your problem >> and it doesn't address the wider issue. It is basically a work-around for >> your use-case, and is introducing yet another behaviour on top of the >> already inconsistent behaviour we have today. >> >> Of course we need anything new that is added to be able to match the >> current behaviour, which will be more and more difficult the more random >> switches and config options we have in mappers. So we really do need to >> have a proper solution in thought out, then figure out how to address it. >> >> >>> >>> >>> 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 >>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >>> external.Frank.Thiele(a)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&gt; >>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >>> keycloak-dev(a)lists.jboss.org >>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >>> ignores users that have already logged in before >>> >>> >>> >>> 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. >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; >>> 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 >>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >>> 726112-100 | Sebastian.Schuster(a)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 < >>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >>> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >>> >> 726112-100 | external.Frank.Thiele(a)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&gt; >>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >>> >> external.Frank.Thiele(a)bosch-si.com&gt; >>> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >>> >> >>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>> >> external.Frank.Thiele(a)bosch-si.com% >>> >> 3cmailto: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 >>> >> >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev(a)lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>>

On Thu, 26 Sep 2019 at 11:52, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 25. 09. 19 14:23, Stian Thorgersen wrote: > > Thinking about this some more. I think all mappers for identity brokering > should have an option to select sync-mode: > > * import - only update on first import > * owner - if the idp is the owner of the user (the user has not been > modified within KC, and only has a single IdP link) > * force - always update > > The mappers that today has a behaviour that doesn't match one of the > above could have an option "legacy". > > > On the IdP config itself there should be a default sync-mode user for > mappers that haven't explicitly set the sync-mode. The default value should > be import. > > +1 for this part. With the small note that not all mapper implementations > may need this option. For example UsernameTemplateMapper. > What does UsernameTemplateMapper actually do? Perhaps for those where it doesn't make sense to have an option it should display the sync-mode, but in non-editable mode? > The next piece of the puzzle would be to prevent editing of values that > shouldn't be possible to edit locally. For user attributes that should be > driven by User Profile SPI, where it would be somehow possible to for > example say don't allow editing this attribute if one of the following > IdPs. I'm working on a design proposal for the User Profile SPI currently, > so we can add that as a requirement there. The same feature could be used > for User Federation providers. For roles it is a bit harder, but would be > nice to somehow be able to flag what roles are managed by IdP/user-storage > and which are not. Perhaps we could add some metadata to the role mapping > for that. > > Yes, will be great to have this capability on User Profile SPI. > > I am not sure about metadata for role/group mappings. There will be some > added complexity in that and not sure it deserves the benefits - also > considering that role/group memberships is something, which is editable > just by administrator and not by user himself in account console. > Remember that very often there will be one person configuring Keycloak and setting up the IdPs and a completely different person managing users and roles/groups. I think it would be nice to be able to show that a role/group mapping is managed externally, but I agree it's not the top priority. > Regarding User Profile SPI, I can imagine that it will be nice to have > the ability to automatically update the metadata/requirements based on some > events? For example when we add support for "temporary" users registered > through IDP, those users will be typically read-only. So I can imagine that > when administrator creates IDP with temporary users, there will be an > event, which will automatically add rules to User Profile SPI that all > attributes of such user should be read-only. Similarly when you have > read-only LDAP provider or SSSD provider, you may also want auto-created > User Profile metadata specifying that users should be non-editable. I am > not sure whether to count with this in the User Profile SPI design or not? > Not sure. Right now I've not really covered this part in the user profile design as I haven't really thought it through. I'm kinda thinking about 2 options. First 1 where attributes can have different config based on the source, and another where you define different user profiles. The latter is probably simpler and cleaner. Let's move further discussion on this part elsewhere though. > Marek > > > Would be great to start on a design proposal around this, so we can have > it documented the way it should work. Once we have that and have agreed on > the approach I don't mind having PRs for individual mappers merged as I > appreciate the fact that for this case you want a solution for hardcoded > role mapper quickly without having to do all of the work for all the other > mappers. > > On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> https://issues.jboss.org/browse/KEYCLOAK-8690 >> >> Adding to my point that we need a consistent solution/strategy for all >> mappers. >> >> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> That is an interesting point. I checked some mappers: >>>> >>>> -        AttributeToRoleMapper handles the update like the import >>>> with the exception that in case of an update, the role is deleted if the >>>> attribute is no longer present (I call this for now inverted logic). >>>> >>>> -        ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper >>>> handle an update with the inverted logic only – so they don’t set but only >>>> delete the role. >>>> >>>> -        HardcodeRoleMapper fully ignores updates whereas it could at >>>> least do it the same way as AttributeToRoleMapper. >>>> >>>> -        UserAttributeMapper is even more complex… >>>> >>>> So the currently used IdentityProviderMapper implementations are very >>>> inconsistent and hopefully documented and understood well for and by the >>>> end users. >>>> >>> >>> It is not documented and I doubt anyone can understand how it will >>> function. This is my concern when we have "random" things happening in each >>> mapper without an overall consistent plan. >>> >>> >>>> >>>> >>>> All I am saying is that it will become a breaking change to globally >>>> define this behavior as there are nowadays several, conflicting modes >>>> implemented. Due to that I would like to emphasize that the flag >>>> introduction (“handleUpdateToo”) still seems as the solution with the >>>> lowest friction. >>>> >>> >>> Adding a flag to an individual mapper is just a solution to your >>> problem and it doesn't address the wider issue. It is basically a >>> work-around for your use-case, and is introducing yet another behaviour on >>> top of the already inconsistent behaviour we have today. >>> >>> Of course we need anything new that is added to be able to match the >>> current behaviour, which will be more and more difficult the more random >>> switches and config options we have in mappers. So we really do need to >>> have a proper solution in thought out, then figure out how to address it. >>> >>> >>>> >>>> >>>> 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 >>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >>>> external.Frank.Thiele(a)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&gt; >>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >>>> keycloak-dev(a)lists.jboss.org >>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >>>> ignores users that have already logged in before >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; >>>> 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 >>>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >>>> 726112-100 | Sebastian.Schuster(a)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 < >>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >>>> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >>>> >> 726112-100 | external.Frank.Thiele(a)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&gt; >>>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >>>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >>>> >> external.Frank.Thiele(a)bosch-si.com&gt; >>>> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >>>> >> >>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>> >> external.Frank.Thiele(a)bosch-si.com% >>>> >> 3cmailto: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 >>>> >> >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >>>> >> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >

On Tue, 1 Oct 2019 at 10:29, BIDON Frederic <fredbi(a)yahoo.com&gt; wrote: > I recently made a fix for role mappers to address what is identified > below as case (2) "Sync". > > Following Marek's analysis, I now realize the vast diversity of possible > use cases. > > Regarding any new configuration feature to tune the expected behavior, I > am suggesting to configure this at the level of the identity provider > rather than down to the mapper. > I think in most cases it would be configured at the IdP level, but some would most likely want to override that behaviour at the mapper level. One example here: * User logs in using Google - the IdP is configured with import as the admin wants to manage users within Keycloak after first login, but the profile-url claim is not managed within Keycloak hence that particular mapper is set to sync > > So we could configure identity providers as either "import only", "sync" > with "local admin lock" option. > > Admin locking external roles (and more generally attributes) would be an > attribute at the user level. > Locking attributes and roles is something we want to drive through user profile feature we will be introducing in the future as that will be capable of providing metadata around profiles in order for account and admin consoles (and associated REST endpoints) to prevent editing certain attributes of the user. > > > *Frédéric BIDON* > > > frederic.bidon(a)yahoo.com > > > > On Friday, September 27, 2019, 1:23:04 PM GMT+2, Stian Thorgersen < > sthorger(a)redhat.com&gt; wrote: > > > I'll get a design proposal written up around this, then we have something > to refer to on how we want to address this issue. > > On Fri, 27 Sep 2019 at 12:57, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > > > > > > > On Thu, 26 Sep 2019 at 11:52, Marek Posolda <mposolda(a)redhat.com&gt; > wrote: > > > >> On 25. 09. 19 14:23, Stian Thorgersen wrote: > >> > >> Thinking about this some more. I think all mappers for identity > brokering > >> should have an option to select sync-mode: > >> > >> * import - only update on first import > >> * owner - if the idp is the owner of the user (the user has not been > >> modified within KC, and only has a single IdP link) > >> * force - always update > >> > >> The mappers that today has a behaviour that doesn't match one of the > >> above could have an option "legacy". > >> > >> > >> On the IdP config itself there should be a default sync-mode user for > >> mappers that haven't explicitly set the sync-mode. The default value > should > >> be import. > >> > >> +1 for this part. With the small note that not all mapper > implementations > >> may need this option. For example UsernameTemplateMapper. > >> > > > > What does UsernameTemplateMapper actually do? Perhaps for those where it > > doesn't make sense to have an option it should display the sync-mode, > but > > in non-editable mode? > > > > > >> The next piece of the puzzle would be to prevent editing of values that > >> shouldn't be possible to edit locally. For user attributes that should > be > >> driven by User Profile SPI, where it would be somehow possible to for > >> example say don't allow editing this attribute if one of the following > >> IdPs. I'm working on a design proposal for the User Profile SPI > currently, > >> so we can add that as a requirement there. The same feature could be > used > >> for User Federation providers. For roles it is a bit harder, but would > be > >> nice to somehow be able to flag what roles are managed by > IdP/user-storage > >> and which are not. Perhaps we could add some metadata to the role > mapping > >> for that. > >> > >> Yes, will be great to have this capability on User Profile SPI. > >> > >> I am not sure about metadata for role/group mappings. There will be > some > >> added complexity in that and not sure it deserves the benefits - also > >> considering that role/group memberships is something, which is editable > >> just by administrator and not by user himself in account console. > >> > > Remember that very often there will be one person configuring Keycloak > and > > setting up the IdPs and a completely different person managing users and > > roles/groups. I think it would be nice to be able to show that a > role/group > > mapping is managed externally, but I agree it's not the top priority. > > > >> Regarding User Profile SPI, I can imagine that it will be nice to have > >> the ability to automatically update the metadata/requirements based on > some > >> events? For example when we add support for "temporary" users > registered > >> through IDP, those users will be typically read-only. So I can imagine > that > >> when administrator creates IDP with temporary users, there will be an > >> event, which will automatically add rules to User Profile SPI that all > >> attributes of such user should be read-only. Similarly when you have > >> read-only LDAP provider or SSSD provider, you may also want > auto-created > >> User Profile metadata specifying that users should be non-editable. I > am > >> not sure whether to count with this in the User Profile SPI design or > not? > >> > > Not sure. Right now I've not really covered this part in the user > profile > > design as I haven't really thought it through. I'm kinda thinking about > 2 > > options. First 1 where attributes can have different config based on the > > source, and another where you define different user profiles. The > latter is > > probably simpler and cleaner. Let's move further discussion on this part > > elsewhere though. > > > >> Marek > >> > >> > >> Would be great to start on a design proposal around this, so we can > have > >> it documented the way it should work. Once we have that and have > agreed on > >> the approach I don't mind having PRs for individual mappers merged as I > >> appreciate the fact that for this case you want a solution for > hardcoded > >> role mapper quickly without having to do all of the work for all the > other > >> mappers. > >> > >> On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; > >> wrote: > >> > >>> https://issues.jboss.org/browse/KEYCLOAK-8690 > >>> > >>> Adding to my point that we need a consistent solution/strategy for all > >>> mappers. > >>> > >>> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; > >>> wrote: > >>> > >>>> > >>>> > >>>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, > >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> > >>>>> That is an interesting point. I checked some mappers: > >>>>> > >>>>> - AttributeToRoleMapper handles the update like the import > >>>>> with the exception that in case of an update, the role is deleted > if the > >>>>> attribute is no longer present (I call this for now inverted logic). > >>>>> > >>>>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper > >>>>> handle an update with the inverted logic only – so they don’t set > but only > >>>>> delete the role. > >>>>> > >>>>> - HardcodeRoleMapper fully ignores updates whereas it could > at > >>>>> least do it the same way as AttributeToRoleMapper. > >>>>> > >>>>> - UserAttributeMapper is even more complex… > >>>>> > >>>>> So the currently used IdentityProviderMapper implementations are > very > >>>>> inconsistent and hopefully documented and understood well for and > by the > >>>>> end users. > >>>>> > >>>> > >>>> It is not documented and I doubt anyone can understand how it will > >>>> function. This is my concern when we have "random" things happening > in each > >>>> mapper without an overall consistent plan. > >>>> > >>>> > >>>>> > >>>>> > >>>>> All I am saying is that it will become a breaking change to globally > >>>>> define this behavior as there are nowadays several, conflicting > modes > >>>>> implemented. Due to that I would like to emphasize that the flag > >>>>> introduction (“handleUpdateToo”) still seems as the solution with > the > >>>>> lowest friction. > >>>>> > >>>> > >>>> Adding a flag to an individual mapper is just a solution to your > >>>> problem and it doesn't address the wider issue. It is basically a > >>>> work-around for your use-case, and is introducing yet another > behaviour on > >>>> top of the already inconsistent behaviour we have today. > >>>> > >>>> Of course we need anything new that is added to be able to match the > >>>> current behaviour, which will be more and more difficult the more > random > >>>> switches and config options we have in mappers. So we really do need > to > >>>> have a proper solution in thought out, then figure out how to > address it. > >>>> > >>>> > >>>>> > >>>>> > >>>>> 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 > >>>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | > >>>>> external.Frank.Thiele(a)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&gt; > >>>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 > >>>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; > >>>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < > >>>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, > >>>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; > >>>>> keycloak-dev(a)lists.jboss.org > >>>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper > >>>>> ignores users that have already logged in before > >>>>> > >>>>> > >>>>> > >>>>> 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. > >>>>> > >>>>> > >>>>> > >>>>> 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. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; > >>>>> 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 > >>>>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 > >>>>> 726112-100 | Sebastian.Schuster(a)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 < > >>>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; > >>>>> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 > >>>>> >> 726112-100 | external.Frank.Thiele(a)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&gt; > >>>>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 > >>>>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < > >>>>> >> external.Frank.Thiele(a)bosch-si.com&gt; > >>>>> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> > >>>>> >> > >>>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: > >>>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: > >>>>> >> external.Frank.Thiele(a)bosch-si.com% > >>>>> >> 3cmailto: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 > >>>>> >> > >>>>> >> _______________________________________________ > >>>>> >> keycloak-dev mailing list > >>>>> >> keycloak-dev(a)lists.jboss.org > >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> >> > >>>>> >> > >>>>> > _______________________________________________ > >>>>> > keycloak-dev mailing list > >>>>> > keycloak-dev(a)lists.jboss.org > >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > > >>>>> > _______________________________________________ > >>>>> > keycloak-dev mailing list > >>>>> > keycloak-dev(a)lists.jboss.org > >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>>> > >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

We would like to contribute in this area. For our current requirements and to fit our timeline we will use our own SPI mappers. However, we think it would be cool to sort this out upstream and I think we should be able to do this.

I think I we will first collect the current behavior of the existing mappers. Did you find time to work on the design proposal, Stian?

Some random issues I found we might have to consider: 1. Technically, all mappers/importers are called mappers. But some of them have “xyz Importer” as their display name (actually the one that only import). If we extend them to also support sync, we will have to change their names and that would be visible to the admins. Even if the behavior stays the same, the changed name might be confusing. But maybe that’s not a big thing.

2. Should the username template importer also support updating the username on subsequent logins and if yes, only if edit username is allowed in realm settings?

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 Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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&gt; *Gesendet:* Mittwoch, 2. Oktober 2019 13:53 *An:* BIDON Frederic <fredbi(a)yahoo.com&gt; *Cc:* Marek Posolda <mposolda(a)redhat.com>; keycloak-dev(a)lists.jboss.org; EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < external.Frank.Thiele(a)bosch-si.com>; Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster(a)bosch-si.com&gt; *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before I can work on the design proposal around this (should be ready this or next week). However, the core team won't be able to prioritize this for some time. Is there anyone interested in contributing around this? On Wed, 2 Oct 2019 at 13:46, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: On Tue, 1 Oct 2019 at 10:29, BIDON Frederic <fredbi(a)yahoo.com&gt; wrote: I recently made a fix for role mappers to address what is identified below as case (2) "Sync". Following Marek's analysis, I now realize the vast diversity of possible use cases. Regarding any new configuration feature to tune the expected behavior, I am suggesting to configure this at the level of the identity provider rather than down to the mapper. I think in most cases it would be configured at the IdP level, but some would most likely want to override that behaviour at the mapper level. One example here: * User logs in using Google - the IdP is configured with import as the admin wants to manage users within Keycloak after first login, but the profile-url claim is not managed within Keycloak hence that particular mapper is set to sync So we could configure identity providers as either "import only", "sync" with "local admin lock" option. Admin locking external roles (and more generally attributes) would be an attribute at the user level. Locking attributes and roles is something we want to drive through user profile feature we will be introducing in the future as that will be capable of providing metadata around profiles in order for account and admin consoles (and associated REST endpoints) to prevent editing certain attributes of the user. *Frédéric BIDON* frederic.bidon(a)yahoo.com On Friday, September 27, 2019, 1:23:04 PM GMT+2, Stian Thorgersen < sthorger(a)redhat.com&gt; wrote: I'll get a design proposal written up around this, then we have something to refer to on how we want to address this issue. On Fri, 27 Sep 2019 at 12:57, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On Thu, 26 Sep 2019 at 11:52, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > >> On 25. 09. 19 14:23, Stian Thorgersen wrote: >> >> Thinking about this some more. I think all mappers for identity brokering >> should have an option to select sync-mode: >> >> * import - only update on first import >> * owner - if the idp is the owner of the user (the user has not been >> modified within KC, and only has a single IdP link) >> * force - always update >> >> The mappers that today has a behaviour that doesn't match one of the >> above could have an option "legacy". >> >> >> On the IdP config itself there should be a default sync-mode user for >> mappers that haven't explicitly set the sync-mode. The default value should >> be import. >> >> +1 for this part. With the small note that not all mapper implementations >> may need this option. For example UsernameTemplateMapper. >> > > What does UsernameTemplateMapper actually do? Perhaps for those where it > doesn't make sense to have an option it should display the sync-mode, but > in non-editable mode? > > >> The next piece of the puzzle would be to prevent editing of values that >> shouldn't be possible to edit locally. For user attributes that should be >> driven by User Profile SPI, where it would be somehow possible to for >> example say don't allow editing this attribute if one of the following >> IdPs. I'm working on a design proposal for the User Profile SPI currently, >> so we can add that as a requirement there. The same feature could be used >> for User Federation providers. For roles it is a bit harder, but would be >> nice to somehow be able to flag what roles are managed by IdP/user-storage >> and which are not. Perhaps we could add some metadata to the role mapping >> for that. >> >> Yes, will be great to have this capability on User Profile SPI. >> >> I am not sure about metadata for role/group mappings. There will be some >> added complexity in that and not sure it deserves the benefits - also >> considering that role/group memberships is something, which is editable >> just by administrator and not by user himself in account console. >> > Remember that very often there will be one person configuring Keycloak and > setting up the IdPs and a completely different person managing users and > roles/groups. I think it would be nice to be able to show that a role/group > mapping is managed externally, but I agree it's not the top priority. > >> Regarding User Profile SPI, I can imagine that it will be nice to have >> the ability to automatically update the metadata/requirements based on some >> events? For example when we add support for "temporary" users registered >> through IDP, those users will be typically read-only. So I can imagine that >> when administrator creates IDP with temporary users, there will be an >> event, which will automatically add rules to User Profile SPI that all >> attributes of such user should be read-only. Similarly when you have >> read-only LDAP provider or SSSD provider, you may also want auto-created >> User Profile metadata specifying that users should be non-editable. I am >> not sure whether to count with this in the User Profile SPI design or not? >> > Not sure. Right now I've not really covered this part in the user profile > design as I haven't really thought it through. I'm kinda thinking about 2 > options. First 1 where attributes can have different config based on the > source, and another where you define different user profiles. The latter is > probably simpler and cleaner. Let's move further discussion on this part > elsewhere though. > >> Marek >> >> >> Would be great to start on a design proposal around this, so we can have >> it documented the way it should work. Once we have that and have agreed on >> the approach I don't mind having PRs for individual mappers merged as I >> appreciate the fact that for this case you want a solution for hardcoded >> role mapper quickly without having to do all of the work for all the other >> mappers. >> >> On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> https://issues.jboss.org/browse/KEYCLOAK-8690 >>> >>> Adding to my point that we need a consistent solution/strategy for all >>> mappers. >>> >>> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> That is an interesting point. I checked some mappers: >>>>> >>>>> - AttributeToRoleMapper handles the update like the import >>>>> with the exception that in case of an update, the role is deleted if the >>>>> attribute is no longer present (I call this for now inverted logic). >>>>> >>>>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper >>>>> handle an update with the inverted logic only – so they don’t set but only >>>>> delete the role. >>>>> >>>>> - HardcodeRoleMapper fully ignores updates whereas it could at >>>>> least do it the same way as AttributeToRoleMapper. >>>>> >>>>> - UserAttributeMapper is even more complex… >>>>> >>>>> So the currently used IdentityProviderMapper implementations are very >>>>> inconsistent and hopefully documented and understood well for and by the >>>>> end users. >>>>> >>>> >>>> It is not documented and I doubt anyone can understand how it will >>>> function. This is my concern when we have "random" things happening in each >>>> mapper without an overall consistent plan. >>>> >>>> >>>>> >>>>> >>>>> All I am saying is that it will become a breaking change to globally >>>>> define this behavior as there are nowadays several, conflicting modes >>>>> implemented. Due to that I would like to emphasize that the flag >>>>> introduction (“handleUpdateToo”) still seems as the solution with the >>>>> lowest friction. >>>>> >>>> >>>> Adding a flag to an individual mapper is just a solution to your >>>> problem and it doesn't address the wider issue. It is basically a >>>> work-around for your use-case, and is introducing yet another behaviour on >>>> top of the already inconsistent behaviour we have today. >>>> >>>> Of course we need anything new that is added to be able to match the >>>> current behaviour, which will be more and more difficult the more random >>>> switches and config options we have in mappers. So we really do need to >>>> have a proper solution in thought out, then figure out how to address it. >>>> >>>> >>>>> >>>>> >>>>> 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 >>>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >>>>> external.Frank.Thiele(a)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&gt; >>>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >>>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >>>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >>>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >>>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >>>>> keycloak-dev(a)lists.jboss.org >>>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >>>>> ignores users that have already logged in before >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; >>>>> 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 >>>>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >>>>> 726112-100 | Sebastian.Schuster(a)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 < >>>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >>>>> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >>>>> >> 726112-100 | external.Frank.Thiele(a)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&gt; >>>>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >>>>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >>>>> >> external.Frank.Thiele(a)bosch-si.com&gt; >>>>> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >>>>> >> >>>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>>> >> external.Frank.Thiele(a)bosch-si.com% >>>>> >> 3cmailto: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 >>>>> >> >>>>> >> _______________________________________________ >>>>> >> keycloak-dev mailing list >>>>> >> keycloak-dev(a)lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >> >>>>> >> >>>>> > _______________________________________________ >>>>> > keycloak-dev mailing list >>>>> > keycloak-dev(a)lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> > >>>>> > _______________________________________________ >>>>> > keycloak-dev mailing list >>>>> > keycloak-dev(a)lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 27. 09. 19 12:57, Stian Thorgersen wrote: On Thu, 26 Sep 2019 at 11:52, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 25. 09. 19 14:23, Stian Thorgersen wrote: > > Thinking about this some more. I think all mappers for identity brokering > should have an option to select sync-mode: > > * import - only update on first import > * owner - if the idp is the owner of the user (the user has not been > modified within KC, and only has a single IdP link) > * force - always update > > The mappers that today has a behaviour that doesn't match one of the > above could have an option "legacy". > > > On the IdP config itself there should be a default sync-mode user for > mappers that haven't explicitly set the sync-mode. The default value should > be import. > > +1 for this part. With the small note that not all mapper implementations > may need this option. For example UsernameTemplateMapper. > What does UsernameTemplateMapper actually do? Perhaps for those where it doesn't make sense to have an option it should display the sync-mode, but in non-editable mode? It allows to specify how should look username of the Keycloak user, which was registered through this Idp. Updating of username of already existing Keycloak user is not yet supported by this mapper. We can eventually add support for it during this work, but question is what should be default mode in this mapper? For example if updating usernames is disabled for the realm and you have IDP with value "owner", you probably don't want that UsernameTemplateMapper will inherit value "owner", because administrator doesn't expect usernames of existing user to be updated.

> The next piece of the puzzle would be to prevent editing of values that > shouldn't be possible to edit locally. For user attributes that should be > driven by User Profile SPI, where it would be somehow possible to for > example say don't allow editing this attribute if one of the following > IdPs. I'm working on a design proposal for the User Profile SPI currently, > so we can add that as a requirement there. The same feature could be used > for User Federation providers. For roles it is a bit harder, but would be > nice to somehow be able to flag what roles are managed by IdP/user-storage > and which are not. Perhaps we could add some metadata to the role mapping > for that. > > Yes, will be great to have this capability on User Profile SPI. > > I am not sure about metadata for role/group mappings. There will be some > added complexity in that and not sure it deserves the benefits - also > considering that role/group memberships is something, which is editable > just by administrator and not by user himself in account console. > Remember that very often there will be one person configuring Keycloak and setting up the IdPs and a completely different person managing users and roles/groups. I think it would be nice to be able to show that a role/group mapping is managed externally, but I agree it's not the top priority. > Regarding User Profile SPI, I can imagine that it will be nice to have > the ability to automatically update the metadata/requirements based on some > events? For example when we add support for "temporary" users registered > through IDP, those users will be typically read-only. So I can imagine that > when administrator creates IDP with temporary users, there will be an > event, which will automatically add rules to User Profile SPI that all > attributes of such user should be read-only. Similarly when you have > read-only LDAP provider or SSSD provider, you may also want auto-created > User Profile metadata specifying that users should be non-editable. I am > not sure whether to count with this in the User Profile SPI design or not? > Not sure. Right now I've not really covered this part in the user profile design as I haven't really thought it through. I'm kinda thinking about 2 options. First 1 where attributes can have different config based on the source, and another where you define different user profiles. The latter is probably simpler and cleaner. Let's move further discussion on this part elsewhere though. Both options are fine. But will be good to have it automatically added somehow. For example when administrator creates read-only LDAP provider, then in 95% cases, he also wants that LDAP users have all profile fields read-only in account management. So it can be nice if administrator doesn't need to manually create UserProfile for LDAP users as another required step. Where is better place to discuss? In the keycloak-dev thread you mentioned design about user profile design document?

Marek Marek > > > Would be great to start on a design proposal around this, so we can have > it documented the way it should work. Once we have that and have agreed on > the approach I don't mind having PRs for individual mappers merged as I > appreciate the fact that for this case you want a solution for hardcoded > role mapper quickly without having to do all of the work for all the other > mappers. > > On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; > wrote: > >> https://issues.jboss.org/browse/KEYCLOAK-8690 >> >> Adding to my point that we need a consistent solution/strategy for all >> mappers. >> >> On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, >>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> That is an interesting point. I checked some mappers: >>>> >>>> - AttributeToRoleMapper handles the update like the import >>>> with the exception that in case of an update, the role is deleted if the >>>> attribute is no longer present (I call this for now inverted logic). >>>> >>>> - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper >>>> handle an update with the inverted logic only – so they don’t set but only >>>> delete the role. >>>> >>>> - HardcodeRoleMapper fully ignores updates whereas it could at >>>> least do it the same way as AttributeToRoleMapper. >>>> >>>> - UserAttributeMapper is even more complex… >>>> >>>> So the currently used IdentityProviderMapper implementations are very >>>> inconsistent and hopefully documented and understood well for and by the >>>> end users. >>>> >>> >>> It is not documented and I doubt anyone can understand how it will >>> function. This is my concern when we have "random" things happening in each >>> mapper without an overall consistent plan. >>> >>> >>>> >>>> >>>> All I am saying is that it will become a breaking change to globally >>>> define this behavior as there are nowadays several, conflicting modes >>>> implemented. Due to that I would like to emphasize that the flag >>>> introduction (“handleUpdateToo”) still seems as the solution with the >>>> lowest friction. >>>> >>> >>> Adding a flag to an individual mapper is just a solution to your >>> problem and it doesn't address the wider issue. It is basically a >>> work-around for your use-case, and is introducing yet another behaviour on >>> top of the already inconsistent behaviour we have today. >>> >>> Of course we need anything new that is added to be able to match the >>> current behaviour, which will be more and more difficult the more random >>> switches and config options we have in mappers. So we really do need to >>> have a proper solution in thought out, then figure out how to address it. >>> >>> >>>> >>>> >>>> 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 >>>> Tel. +49 30 726112-0 | Fax +49 30 726112-100 | >>>> external.Frank.Thiele(a)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&gt; >>>> *Gesendet:* Mittwoch, 25. September 2019 08:38 >>>> *An:* Marek Posolda <mposolda(a)redhat.com&gt; >>>> *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < >>>> Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, >>>> INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; >>>> keycloak-dev(a)lists.jboss.org >>>> *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper >>>> ignores users that have already logged in before >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; >>>> 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 >>>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 >>>> 726112-100 | Sebastian.Schuster(a)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 < >>>> keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; >>>> > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >>>> >> 726112-100 | external.Frank.Thiele(a)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&gt; >>>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >>>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >>>> >> external.Frank.Thiele(a)bosch-si.com&gt; >>>> >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >>>> >> >>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >>>> >> external.Frank.Thiele(a)bosch-si.com% >>>> >> 3cmailto: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 >>>> >> >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev(a)lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >>>> >> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >

Hi everybody, Sorry for taking so long to respond. What would be the semantics of “owner”? From a mapper perspective, they just offer to act on first logins (“importNewUser()”) or subsequent logins (“updateBrokeredUser()”). Every mapper would act on first login, so this logically means there are only two options left: to update on subsequent logins or not. But maybe I am missing something here?

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 Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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&gt; *Gesendet:* Freitag, 27. September 2019 12:57 *An:* Marek Posolda <mposolda(a)redhat.com&gt; *Cc:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < external.Frank.Thiele(a)bosch-si.com>; Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster(a)bosch-si.com>; keycloak-dev(a)lists.jboss.org *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before On Thu, 26 Sep 2019 at 11:52, Marek Posolda <mposolda(a)redhat.com&gt; wrote: On 25. 09. 19 14:23, Stian Thorgersen wrote: Thinking about this some more. I think all mappers for identity brokering should have an option to select sync-mode: * import - only update on first import * owner - if the idp is the owner of the user (the user has not been modified within KC, and only has a single IdP link) * force - always update The mappers that today has a behaviour that doesn't match one of the above could have an option "legacy". On the IdP config itself there should be a default sync-mode user for mappers that haven't explicitly set the sync-mode. The default value should be import. +1 for this part. With the small note that not all mapper implementations may need this option. For example UsernameTemplateMapper. What does UsernameTemplateMapper actually do? Perhaps for those where it doesn't make sense to have an option it should display the sync-mode, but in non-editable mode? The next piece of the puzzle would be to prevent editing of values that shouldn't be possible to edit locally. For user attributes that should be driven by User Profile SPI, where it would be somehow possible to for example say don't allow editing this attribute if one of the following IdPs. I'm working on a design proposal for the User Profile SPI currently, so we can add that as a requirement there. The same feature could be used for User Federation providers. For roles it is a bit harder, but would be nice to somehow be able to flag what roles are managed by IdP/user-storage and which are not. Perhaps we could add some metadata to the role mapping for that. Yes, will be great to have this capability on User Profile SPI. I am not sure about metadata for role/group mappings. There will be some added complexity in that and not sure it deserves the benefits - also considering that role/group memberships is something, which is editable just by administrator and not by user himself in account console. Remember that very often there will be one person configuring Keycloak and setting up the IdPs and a completely different person managing users and roles/groups. I think it would be nice to be able to show that a role/group mapping is managed externally, but I agree it's not the top priority. Regarding User Profile SPI, I can imagine that it will be nice to have the ability to automatically update the metadata/requirements based on some events? For example when we add support for "temporary" users registered through IDP, those users will be typically read-only. So I can imagine that when administrator creates IDP with temporary users, there will be an event, which will automatically add rules to User Profile SPI that all attributes of such user should be read-only. Similarly when you have read-only LDAP provider or SSSD provider, you may also want auto-created User Profile metadata specifying that users should be non-editable. I am not sure whether to count with this in the User Profile SPI design or not? Not sure. Right now I've not really covered this part in the user profile design as I haven't really thought it through. I'm kinda thinking about 2 options. First 1 where attributes can have different config based on the source, and another where you define different user profiles. The latter is probably simpler and cleaner. Let's move further discussion on this part elsewhere though. Marek Would be great to start on a design proposal around this, so we can have it documented the way it should work. Once we have that and have agreed on the approach I don't mind having PRs for individual mappers merged as I appreciate the fact that for this case you want a solution for hardcoded role mapper quickly without having to do all of the work for all the other mappers. On Wed, 25 Sep 2019 at 12:36, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: https://issues.jboss.org/browse/KEYCLOAK-8690 Adding to my point that we need a consistent solution/strategy for all mappers. On Wed, 25 Sep 2019 at 12:32, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: On Wed, 25 Sep 2019 at 09:42, EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com&gt; wrote: Hi, That is an interesting point. I checked some mappers: - AttributeToRoleMapper handles the update like the import with the exception that in case of an update, the role is deleted if the attribute is no longer present (I call this for now inverted logic). - ClaimToRoleMapper and ExternalKeycloakRoleToRoleMapper handle an update with the inverted logic only – so they don’t set but only delete the role. - HardcodeRoleMapper fully ignores updates whereas it could at least do it the same way as AttributeToRoleMapper. - UserAttributeMapper is even more complex… So the currently used IdentityProviderMapper implementations are very inconsistent and hopefully documented and understood well for and by the end users. It is not documented and I doubt anyone can understand how it will function. This is my concern when we have "random" things happening in each mapper without an overall consistent plan. All I am saying is that it will become a breaking change to globally define this behavior as there are nowadays several, conflicting modes implemented. Due to that I would like to emphasize that the flag introduction (“handleUpdateToo”) still seems as the solution with the lowest friction. Adding a flag to an individual mapper is just a solution to your problem and it doesn't address the wider issue. It is basically a work-around for your use-case, and is introducing yet another behaviour on top of the already inconsistent behaviour we have today. Of course we need anything new that is added to be able to match the current behaviour, which will be more and more difficult the more random switches and config options we have in mappers. So we really do need to have a proper solution in thought out, then figure out how to address it. 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 Tel. +49 30 726112-0 | Fax +49 30 726112-100 | external.Frank.Thiele(a)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&gt; *Gesendet:* Mittwoch, 25. September 2019 08:38 *An:* Marek Posolda <mposolda(a)redhat.com&gt; *Cc:* Schuster Sebastian (INST-CSS/BSV-OS2) < Sebastian.Schuster(a)bosch-si.com>; EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <external.Frank.Thiele(a)bosch-si.com>; keycloak-dev(a)lists.jboss.org *Betreff:* Re: [keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before 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. 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. On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 726112-100 | Sebastian.Schuster(a)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 < keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 >> 726112-100 | external.Frank.Thiele(a)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&gt; >> *Gesendet:* Donnerstag, 19. September 2019 13:51 >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < >> external.Frank.Thiele(a)bosch-si.com&gt; >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> >> >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: >> external.Frank.Thiele(a)bosch-si.com% >> 3cmailto: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 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

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.

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...

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.

Marek On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda(a)redhat.com&gt; 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 > > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax +49 30 > 726112-100 | Sebastian.Schuster(a)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 < > keycloak-dev-bounces(a)lists.jboss.org&gt; 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&gt; > > Cc: keycloak-dev(a)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&gt; 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 Tel. +49 30 726112-0 | Fax +49 30 > >> 726112-100 | external.Frank.Thiele(a)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&gt; > >> *Gesendet:* Donnerstag, 19. September 2019 13:51 > >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) < > >> external.Frank.Thiele(a)bosch-si.com&gt; > >> *Cc:* keycloak-dev(a)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&gt; 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%3chttp:/www.bosch-si.com>> > >> > >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: > >> external.Frank.Thiele(a)bosch-si.com&lt;mailto: > >> external.Frank.Thiele(a)bosch-si.com% > >> 3cmailto: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 > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >