Repository navigation
Replies: 11 comments 40 replies
|
After some more more testing and playing around with this feature, I'd love to get this in preview or even supported state. Are there already any plans to elevate this feature? When can we expect this to happen? Especially in EU and more especially in Germany, when working with external IdPs from government parties (like e.g. bundID (federal IdP in Germany for all citizens) or Elster (federal portal for companies/legal entities), who requires you to delete data after some time of inactivity (which is also required by the GDPR in EU), this feature would ease a lot of deployments and custom extensions around user deletion. And Keycloak is heavily used in Germany from public institutions in conjunction with bundID and Elster...! /cc @ahus1 |
|
Finding customers from the public sector in Germany who are willing to test an "experimental" feature is hard... even if they have in mind that also "preview" features, like the token exchange, seem to never get to supported mode (yes, I know there are reasons for it, but people out there in the wild don't!) However, I've done tests with two customers in limited test environments with Keycloak 23.0. We've connected various external identity providers, with generic SAML and OIDC (no social providers!) and turned "Do not store users" on. After mapping the required and desired roles, groups and attributes, we encountered no problems. |
|
IMO the documentation is already mentioning all relevant information, at least from that what I tested. I just added a little not to pay attention to the |
|
With KC24 there seems to be a new bug in admin-ui/-api when trying to access the user details: #28666 |
|
Update on the issue: Thank you for @hmlnarik for fixing this. We're planning to backport this fix to KC24. |
|
We are currently testing this feature and so far it looks pretty good. But we are not finished with testing yet. If we are running into some problems we will let you know :-) |
|
Thank you for this feedback, this is exactly what we are looking for! If you find that some documentation is missing, please consider adding the necessary bits to https://github.com/keycloak/keycloak/blob/main/docs/transient-users.md |
|
Instead of using hardcoded mappers, we could also have "default roles for transient users" on realm level or in identity provider level, same could apply for groups. This would ease the configuration a bit. |
|
I think with the proposed group workaround having dedicated "default-roles" / "default-groups" for transient users is not necessary for GA. |
|
About the proposed documentation change: With @dasniko testing/exploring/working with the feature at the moment, he could be a reviewer for this and provide feedback. |
|
Okay, then I'll send a PR for this. |
|
PR is here: #28874 |
|
The PR is now merged. Thanks @thomasdarimont for this update! |
|
The user links in the sessions listing do not work for transient users. I suggest to disable the links for those users and make it possible to distinguish persistent users from transient users. |
|
@thomasdarimont - when discussing those items, please clarify if you think they should be implemented before this feature is GA or after. Like everything else, it is a matter of prioritization. In this thread, while it is ok to collect some future enhancement, I would like to focus on what is essential to get it to the next stage (preview or even supported). |
|
I think this is quite easy to add and should be in before this goes GA. |
|
@thomasdarimont - no-one is keeping anyone from implementing it, as long as they find a reviewer. IMHO prioritization should be more along the following lines:
|
|
I just sent a PR for showing the indicator in the list: #28882 |
|
The PR is now merged. Thanks @thomasdarimont for this update! |
|
The documentation looks okay from my perspective but how about adding an additional part about how to prevent user-profile-review. In case of transient users we will always have the |
|
A PR would be welcome. Thanks! |
|
Added a PR #28889 |
|
The PR is now merged. Thanks @Captain-P-Goldfish for this update! |
|
I want to see it to be supported before. Ve want to use it for the same reason described by @dasniko #26637 (reply in thread) |
|
We have been doing some very light testing on this feature, and noticed that the transient users are not linked to the identity provider (see sessions -> user details -> identity provider links tab). Is that working as intended or a bug? |
|
I just tested the transient users feature with the organizations. In the admin UI, I don't see users in the organization -> members tab, but this is expected, as there are no stored users. ✔ When I access a transient user through the sessions menu, then click on the users details and go to the organizations tab, the call to the endpoint Can we expect a transition of this experimental feature to preview or support soon? |
|
Transient users feature is most likely going to be removed. It has a number of issues like:
What we should do instead is introduce some automatic user deletion policies; that can automatically delete a user with no sessions if it's a brokered user, maybe even after a certain grace period (delete brokered user after 7 days of inactivity for example). Please see #38108 as a follow-up to this. |
|
We use (not in production yet) this feature in our implementation too, so We would be interested to hear if this is going to be removed. |
|
We'll want to have #39888 completed before we remove transient users; I would think we'd remove that in 27, but not 100% sure at this point. @pedroigor FIY |
|
thanks for sharing that @stianst. I think this is a very good alternative to the transient-users feature. |
|
We're leveraging this feature, too. |
|
The transient users feature may have its shortcomings, as described by @stianst, but there are good reasons to keep it available when Keycloak is used as a thin SSO/broker layer, rather than as a full-blown IAM system with its own user database. As already mentioned, in the EU, storing personal data in a database, even briefly and regardless of how aggressive the deletion policy may be, effectively changes the outcome of the Data Protection Impact Assessment for such deployments and can ultimately kick you out of the game. User consent and T&C are also not sufficient workarounds. In SSO/broker scenarios, asking users for consent to store their personal data is problematic by design, since the entire purpose of the flow is to process, not store, the profile(s) of a user retrieved from remote user repositories. While the line between a “transient user” and “temporarily stored data” can be blurry, being able to say “we do not store user data in the database” is often essential. I believe the maintainers should consider keeping the transient users feature available. |
|
Do you have any source for your claim that there is a difference between storing data in a database and storing it in memory? |
|
from an architectural point of view, the difference is pretty clear. #39888, might be a good mitigation, still, there are plenty of deployment scenarios (like auth brokering) where a db with users data isn’t needed at all, and the transient-users feature is a great fit. Even advanced on-the-fly reconciliation flows can be built with transient users, at the cost of a few extra API calls. And while transient users don’t fit every use case, my suggestion is to keep the option available for lightweight SSO/broker setups. It should be up to the implementer to decide what to use and how to handle any limitations of the feature |
|
I wanted to add a use case for So replacing this with a user deletion policy is not enough, we need to ensure that no persistent data is stored at all (like @nvoutsin already pointed out) AND that subsequent "logins" in this realm do not re-use any data from a previously linked account or trigger SSO. So removing this would actually hurt quite a bit. |
|
We also recently discussed this topic.
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi @hmlnarik
I'm currently testing the experimental transient users which were introduced with #23977.
So far, it works like expected, but I experienced that a transient user doesn't get the
default-roles-<realm>role associated. Is this intended or just missing?After a while I discovered somewhere in the docs (or just release notes?) that I have to set this mapping explicitly. After adding the
default-roles-...in the IdP mappers as a "hardcoded role mapper", it works like a charm. But it isn't/wasn't obvious for me to do this extra step, as regular users will get assigned to the default roles automatically.Thanks & regards!
All reactions