[keycloak-dev] A newly added Hardcoded Role mapper ignores users that have already logged in before
Marek Posolda
mposolda at redhat.com
Thu Sep 26 05:55:53 EDT 2019
On 25. 09. 19 12:27, Stian Thorgersen wrote:
>
>
> On Wed, 25 Sep 2019 at 10:22, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> On 25. 09. 19 8:37, Stian Thorgersen wrote:
>> Adding config options on a single mappers is not really a great
>> solution. We need to make sure there is a consistent approach
>> throughout. We probably don't have consistent and predictable
>> behaviour today, but I would rather not make it worse by
>> introducing random config options on mappers.
>>
>> Main question is if this should be controlled on individual
>> mappers or if it should mainly be a config on the identity provider.
>>
>> Having the config on the identity provider would make more sense
>> as it would be simpler to configure and it would avoid corner cases.
>
> I am not very sure about the single option at Idp level.
>
> IMO in many cases, the requirement is to have "mixed" mode. For
> example customer wants that profile info (firstName, lastName,
> email etc) are managed from Idp and always want to use latest
> stuff from Idp during every login, but the role mappings should be
> managed entirely by Keycloak. Or possibly roles are just initially
> imported from Idp, but then managed by Keycloak etc.
>
> Some fine-grained control is needed in option 2 I listed below, but it
> needs to be designed properly and made consistent, not just a bunch of
> random options on individual mappers.
>
>>
>> There's probably at least 3 different modes for identity
>> brokering that should be supported:
>>
>> 1) Import only - User is only imported if it doesn't exist. If
>> user already exists nothing is updated.
>> 2) Sync - Allow changes to the user within Keycloak, but also
>> sync changes from external IdP
>> 3) External - Do not allow any changes to the user within
>> Keycloak as the user should be fully managed from the external IdP
>>
>> Option 1 is trivial.
>>
>> Option 2 can be very complicated. Take the example of the
>> hardcoded role for instance. User first logs in, the role is
>> added. An admin then removes the role from the user. User logs in
>> again and the role is re-added. Same example can be applied to
>> last name for instance. User logs in. 6 months later the user
>> changes the last name in Keycloak account console, but then next
>> day when they re-login the last name is changed back.
>>
>> Option 3 is relatively trivial, but would need some tweaks within
>> Keycloak. A user that is fully externally managed should not be
>> able to use Keycloak account console and should be view-only in
>> the admin console.
>
> 1 is what we already have.
>
> 2 is what we will have if we add the switch to the mapper or Idp.
> IMO this won't be complicated to implement, but I agree that
> behaviour is quite tricky... It is maybe fine for many
> deployments, but it will need to be clearly documented that update
> on Keycloak side will be lost upon next login to Idp.
>
> With sync you expect something smarter than just having individual
> mappers overwrite local changes. It is not very elegant to allow a
> user to change their first name in the KC account console, if it will
> just be overwritten next login. Same it is not very elegant to allow
> admins removing roles that will just be added again on next login.
>
> 3 will be more complicated to implement and will require changes
> to SPI of IdentityProviderMapper. For example we may need
> IdentityProviderMappers to return UserModel, so that they are able
> to return proxy object (subclass of UserModelDelegate) similarly
> like UserStorage providers do. This will allow lots of flexibility
> and mixed mode (EG. support for profile data to be managed by Idp
> and being read-only in Keycloak, but role memberships to be
> managed by Keycloak and hence editable from Keycloak). Problem is,
> that there are lots of corner-cases with that approach. Especially
> user can be linked to multiple Identity providers, but the
> UserModel proxy object should be always the same...
>
> You've absolutely lost me here. In option 3 a user is fully managed
> externally and no local changes is permitted.
Sorry, now I see that what I wrote here is quite confusing :) I was just
thinking loud about the complexity of option 3 (external users, which
shouldn't be editable from Keycloak) with current capabilities and about
challenges around supporting it. But perhaps User Profile SPI is a
solution for it.
Marek
> Another point is, that we have the use-case from many people, that
> Idp user should be "temporary" in Keycloak (EG. read-only and not
> written to Keycloak DB at all) and also the requirement to
> register the Idp user to specified userStorage provider. If we do
> any major change in the IdentityProviderMappers and related
> Keycloak codebase, we should probably address this use-case as
> well at the same time IMO.
>
> Agree, supporting temporary users is mostly about adding support for
> option 3 and having some temporary way of storing users (Infinispan I
> guess).
>
> Marek
>
>>
>>
>>
>>
>>
>> On Mon, 23 Sep 2019 at 22:21, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>> Makes sense to me. From me +1 for this.
>>
>> Marek
>>
>> On 20. 09. 19 15:57, Schuster Sebastian (INST-CSS/BSV-OS2) wrote:
>> > I guess the point was just to add a configuration flag to
>> the mapper enabling the update on existing users.
>> > If that flag is not there or set to false, the old behavior
>> stays.
>> >
>> > Best regards,
>> > Sebastian
>> >
>> >
>> > Mit freundlichen Grüßen / Best regards
>> >
>> > Dr.-Ing. Sebastian Schuster
>> >
>> > Open Source Services (INST-CSS/BSV-OS2)
>> > Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
>> Berlin | GERMANY | www.bosch-si.com <http://www.bosch-si.com>
>> > Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Telefax
>> +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>> <mailto:Sebastian.Schuster at 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 at lists.jboss.org
>> <mailto:keycloak-dev-bounces at lists.jboss.org>
>> <keycloak-dev-bounces at lists.jboss.org
>> <mailto:keycloak-dev-bounces at lists.jboss.org>> Im Auftrag von
>> Stian Thorgersen
>> > Gesendet: Freitag, 20. September 2019 15:25
>> > An: EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2)
>> <external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com>>
>> > Cc: keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at 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 at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com>> wrote:
>> >
>> >> Hi,
>> >>
>> >>
>> >>
>> >> What if I implement a newer version of the Hardcoded Role
>> mapper that
>> >> has a (optional, as configuration migration case) flag to
>> activate
>> >> update handling. So when the flag is set to false or not
>> set at all
>> >> (migration case), then behavior is as of today. If the
>> flag is set,
>> >> the import and update functions behave the same way.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Mit freundlichen Grüßen / Best regards
>> >>
>> >>
>> >> *Frank Thiele *
>> >> Open Source Services 2 - Product Group Customer Success
>> Services
>> >> (INST-CSS/BSV-OS2)
>> >> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109
>> Berlin |
>> >> GERMANY | www.bosch-si.com <http://www.bosch-si.com> Tel.
>> +49 30 726112-0 | Fax +49 30
>> >> 726112-100 | external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at 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 at redhat.com
>> <mailto:sthorger at redhat.com>>
>> >> *Gesendet:* Donnerstag, 19. September 2019 13:51
>> >> *An:* EXTERNAL Thiele Frank (TNG, INST-CSS/BSV-OS2) <
>> >> external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com>>
>> >> *Cc:* keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at 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 at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com>> wrote:
>> >>
>> >> Hello,
>> >>
>> >>
>> >>
>> >> In our project, we use the "Hardcoded role" mapper within
>> a configured
>> >> Identity Provider (also a Keycloak instance, in our case
>> the same but
>> >> a different realm) to describe that each user logging in
>> via Keycloak
>> >> shall be given a certain role.
>> >>
>> >> This works perfectly if the mapper is configured before
>> the first
>> >> login of the user. The configured role is granted to the
>> (cloned) user
>> >> when he logs in the first time via Keycloak.
>> >>
>> >> But when another "Hardcoded role" mapper is added to
>> configure another
>> >> role, then the user is not given the other role when he
>> logs in. Only
>> >> new users logging in the first time get both roles assigned.
>> >>
>> >>
>> >>
>> >> Is this on purpose or a bug?
>> >>
>> >>
>> >>
>> >> Mit freundlichen Grüßen / Best regards
>> >>
>> >>
>> >>
>> >> Frank Thiele
>> >>
>> >>
>> >>
>> >> Open Source Services 2 - Product Group Customer Success
>> Services
>> >> (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH |
>> Ullsteinstr. 128
>> >> |
>> >> 12109 Berlin | GERMANY | www.bosch-si.com
>> <http://www.bosch-si.com><http://www.bosch-si.com<
>> >> http://www.bosch-si.com%3chttp:/www.bosch-si.com
>> <http://www.bosch-si.com>>>
>> >>
>> >> external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com><mailto:
>> >> external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com><mailto:
>> >> external.Frank.Thiele at bosch-si.com
>> <mailto:external.Frank.Thiele at bosch-si.com>%
>> >> 3cmailto:external.Frank.Thiele at bosch-si.com
>> <mailto:3cmailto%3Aexternal.Frank.Thiele at 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 at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
More information about the keycloak-dev
mailing list