-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Impersonation for non-persistent authenticators #648
Comments
How do you expect impersonation for stateless authentication to work? |
we have this scenario (simplified) for JwtAuthenticator:
|
and the thing is, i couldn't find any reason for |
Where will you store the standard token if authentication is stateless? |
nowhere. if we carry information about the impersonator, we can simply issue a new one when he decides to stop impersonating. |
So how would |
Of course I am able to do that. But sorry... I don't understand, what we are talking about :) If you insist, that the ImpersonationInterface extending PersistenceInterface is necessary and you don't want to change it, just close this. |
but to answer your question: the |
Whenever someone opens an RFC we first try to understand the use case before we take a decision on whether to go ahead with the changes, hence the questions. |
i added a proposed change, so you can consider. |
Part of the ImpersonationInterface is that it remembers what your identity was before the impersonation began, and can restore that with I'm interested in how you see these method working with stateless authentication methods? For example basic auth or token based auth? Is that behavior you are expecting from the framework or are application authenticators that implement the |
OK. But do you think, that the fact, that it will be impossible for some authenticators to implement |
I agree that each authenticator will need to manage the state themselves. Having the inheritance formalizes that there needs to be some persistent state managed somewhere, and gives application developers the necessary hooks to have state clearing integrated well. For example Impersonation requires some state to be persisted somewhere and having an authenticator pretend it is stateless but also have persistent state feels awkward. |
so even this is possible to achieve with JwtAuthenticator, you think it's not worth merging? |
please let me know. i wanted to have this process unified using component and if this is not merged, i'd need to think of other solution. thanks |
This isn't possible with the JwtAuthenticator today. Or are you saying it could be done with JWT authenticator. |
Yes. I wanted to say it could be done. |
so please can we somehow close this? either as accepted or rejected? thank you |
My issue with this change is that removing the
If you're proposing we have a stateful JwtAuthenticator that enables impersonation, then that is something that is more interesting. As a framework I think we should be helping enable common patterns, and having JWT authentication alongside an impersonation mechanic fits nicely with those goals. Edit: To clarify, the 'state' could be held within the JWT token and not elsewhere. |
That's what he suggested in an earlier comment #648 (comment). When impersonification is started they generate a new token which contains additional info regarding the user being impersonated and on stopping revert back to a "normal" token. How the token switching is done can be left to the users and we don't need to do anything extra in the plugin, just update the ImpersonationInterface as suggested. |
Ok. Good to see that we're thinking about the token switching in a similar way.
Shouldn't we at least provider an implementation of JwtToken with Impersonation? Having looked at the code further and talked through how the impersonation would work with a stateless authenticator, I am sold on removing the inheritance with |
I am not opposed to it if someone wants to provide an implementation :) |
So is this still to be kept open? The related PR got merged. |
Hi
we were planning to implement impersonation for a stateless authenticator and it looked logical to me, to implement
ImpersonationInterface
, so we can use auth component for that. But this interface extendsPersistenceInterface
. I don't see any logic in this inheritance. Could you please explain, if this is needed? If not, I can create PR for the necessary changes.Thank you
The text was updated successfully, but these errors were encountered: