[keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219
Stian Thorgersen
sthorger at redhat.com
Wed Jan 25 07:02:09 EST 2017
Please have patience rather than repeat yourself. I don't really need 3
emails about the same thing in my mailbox as I have loads of email to get
through in a day!
I don't really see the use-case for this. Impersonation is specifically for
a user to impersonate another user. As such there has to be a front-end
application as users don't go around manually obtaining tokens to invoke
backend services.
On 23 January 2017 at 15:30, Ritesh Garg <ritesh.garg at outlook.com> wrote:
> Hello,
>
>
> Any thoughts on this?
>
>
> Thanks,
>
> Ritesh
>
> ________________________________
> From: Ritesh Garg <ritesh.garg at outlook.com>
> Sent: Thursday, January 19, 2017 9:47 AM
> To: keycloak-dev at lists.jboss.org
> Subject: Keycloak Impersonation feature | KEYCLOAK-4219
>
> Hello everyone,
>
> As of now, Keycloak supports impersonation by an admin user at the front
> end application level. However, if someone is using JWT token based API
> security, there is no existing way to get a user's JWT token "on behalf" of
> the user by admin u.
>
> I understand and agree with Stian Thorgersen that this is not just adding
> the return of a JWT token to the current impersonation endpoint. But I
> believe if keycloak supports impersonation; we should support that for API
> security as well and not just front-end applications.
>
> If we decide to incorporate it; one implementation approach can be to
> introduce an impersonation grant type which would perform client and admin
> user authentication before granting a token on behalf of the user it is
> requested for. Please let me know if this sounds completely absurd to you
> guys.
>
> Thoughts?
>
> Thanks,
> Ritesh Garg
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list