Replies: 5 comments 30 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
With KC24 there seems to be a new bug in admin-ui/-api when trying to access the user details: #28666 |
Beta Was this translation helpful? Give feedback.
-
|
Update on the issue: Thank you for @hmlnarik for fixing this. We're planning to backport this fix to KC24. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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 :-) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I think with the proposed group workaround having dedicated "default-roles" / "default-groups" for transient users is not necessary for GA. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, then I'll send a PR for this. |
Beta Was this translation helpful? Give feedback.
-
|
PR is here: #28874 |
Beta Was this translation helpful? Give feedback.
-
|
The PR is now merged. Thanks @thomasdarimont for this update! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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). |
Beta Was this translation helpful? Give feedback.
-
|
I think this is quite easy to add and should be in before this goes GA. |
Beta Was this translation helpful? Give feedback.
-
|
@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:
|
Beta Was this translation helpful? Give feedback.
-
|
I just sent a PR for showing the indicator in the list: #28882 |
Beta Was this translation helpful? Give feedback.
-
|
The PR is now merged. Thanks @thomasdarimont for this update! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
A PR would be welcome. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Added a PR #28889 |
Beta Was this translation helpful? Give feedback.
-
|
The PR is now merged. Thanks @Captain-P-Goldfish for this update! |
Beta Was this translation helpful? Give feedback.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions