Repository navigation
Replies: 3 comments 10 replies
|
To prevent a proliforation of options, shouldn't this be considered prior to including #40309 Should we aim for a generalized expiration parameter / option: expiration=[never|logout] Eventually time intervals would be supported as well. We could have an explicit "default" or just assume that if not specified the default behavior would be assumed - which would be the current handling of marking as temp, but not deleting. |
|
I'm not fully convinced it makes sense to combine the temporary and expiration options. We'd basically have two "never expire" values: one that still marks the admin user as a temporary, and the other doesn't. Once we have the mechanism to expire users (that the Core IAM team is working on), I reckon we won't need the current behaviour (marked as temporary but never expired) – we will either mark the admin as temporary and expire it, or we won't mark it as temporary at all. However, before we implement the proper expiration mechanism (which would need to be done in collaboration with Core IAM), it would IMHO be confusing to have From my perspective we have two options:
|
|
CC @pedroigor as your team is working on the expirations AFAIK. |
|
From the UDS Platform perspective, option no 2 is much better as it would give us a working solution faster. Once all the required bits land in the |
|
My take is that we have a half-baked concept of temporary admins, and we're talking about adding on to that 2 additional boolean options that somewhat conflict with other and neither of which may be supported for long. Given the formal process of deprecation and removal they will still exist for several releases. This does not seem like a good approach.
You would have a default behavior (mark as temporary and never expire), and an explicit behavior via the expiration parameter. We would document the never option as not marking the user as temporary, so that should be clear.
It would be documented and in help that interval values weren't initially accepted. How is that any more confusing than looking for special purpose flags? |
Another approach would be to have that only as a hidden option to provide an unsupported escape hatch for users that really need it. Though it's not really a proper and systematic solution, I'm not too fond of that...
It feels confusing that we'd be saying "expiration" while it'd be truly just removing the temporary flag from the admin. That said, it would make a perfect sense as a preparation for the true expiration support. I think the key question is what is the current ETA for implementing the user expiration and if it'll be suitable for the initial admin too. CC @pedroigor |
|
I haven't waded through all the proposals and counter-proposals, but I do want to sound a note of caution. We need to be very careful not to damage the "out of box" experience. Just having this temporary admin user is already confusing to someone who is trying Keycloak for the first time. Please don't do anything that makes it even more complicated. Someone evaluating Keycloak should be given the simplest, most pleasant encounter possible. |
|
I get the idea behind For one it will be a very bespoke piece of code for this use-case, and awkward to implement. It can't just rely on the user actively logging out, as it's very likely the user don't do that, but rather just let the session expire. Further, this is pretty intrusive. For a quick start / demo scenario it's an additional option I would have to disable. What if there are other things like that down the line? I don't want to have to disable multiple things just to try Keycloak out. For a production scenario maybe I made a mistake or need some extra time to setup things properly? Besides the whole idea of temporary admin accounts is not the best approach in either case; so let's not continue to expand on it, but rather come up with something better. I propose something more along the lines of #41382 |
|
+1 Especially the idea of using |
|
I'm also fully in support of #41382. Sounds like a great path forward that also opens up other doors for compliance. Big +1 from me. |
Uh oh!
There was an error while loading. Please reload this page.
Temporary administrators have been introduced a while back now and have been playing a vital role in other features like recovering lost admin credentials. The code clearly suggests that Temporary Administrators were designed to support expiration time but this extension has been abandoned.
This discussion suggests a different workflow and always deleting temporary Admin Account when they log out. This new functionality would be activated upon a new CLI configuration parameter, for example:
bootstrap-admin user --always-deleteand would be turned on by default.This discussion is also related to:
cc @vmuzikar @shawkins
All reactions