[keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219
Stian Thorgersen
sthorger at redhat.com
Wed Jan 25 07:31:28 EST 2017
On 25 January 2017 at 13:24, Konstantin Gribov <grossws at gmail.com> wrote:
> Hello, Stian.
>
> I have such usecase where app should be able to work on behalf of some
> user for periodic tasks.
>
> But I'm not sure that such case should be implemented using impersonation.
> It's too coarse grained and makes attack surface much larger, since it
> allows to get access token for any scope including offline for impersonated
> user.
>
> Currently I use usernames (which are unique in my case because of my ldap
> contraints on users `cn`s) and a little service to obtain all required info
> (like email, groups/roles) for periodic tasks via Keycloak Admin API using
> service user for this activity. I have to make this service a confidential
> client because of bearer-only lacks support for service accounts (so I hope
> that KEYCLOAK-4156 will come soon).
>
> Another way to do something on behalf of some user would be offline token
> which is intended for such usecases, but it can't be easily integrated to
> our system.
>
Offline tokens are the way your use-case should be solved and we won't add
another approach. Allowing an application to impersonate any arbitrary user
is just plain crazy. It's actually a really god reason we should not
support impersonation through an api.
>
>
> ср, 25 янв. 2017 г. в 15:03, Stian Thorgersen <sthorger at redhat.com>:
>
>> 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
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> --
>
> Best regards,
> Konstantin Gribov
>
More information about the keycloak-dev
mailing list