8:47 a.m.
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
8:30 a.m.
Hello,
Any thoughts on this?
Thanks,
Ritesh
________________________________
From: Ritesh Garg <ritesh.garg(a)outlook.com>
Sent: Thursday, January 19, 2017 9:47 AM
To: keycloak-dev(a)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
6:02 a.m.
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(a)outlook.com> wrote:
Hello,
Any thoughts on this?
Thanks,
Ritesh
________________________________
From: Ritesh Garg <ritesh.garg(a)outlook.com>
Sent: Thursday, January 19, 2017 9:47 AM
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:24 a.m.
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.
ср, 25 янв. 2017 г. в 15:03, Stian Thorgersen <sthorger(a)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(a)outlook.com> wrote:
> Hello,
>
>
> Any thoughts on this?
>
>
> Thanks,
>
> Ritesh
>
> ________________________________
> From: Ritesh Garg <ritesh.garg(a)outlook.com>
> Sent: Thursday, January 19, 2017 9:47 AM
> To: keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Best regards,
Konstantin Gribov
6:31 a.m.
On 25 January 2017 at 13:24, Konstantin Gribov <grossws(a)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(a)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(a)outlook.com> wrote:
>
> > Hello,
> >
> >
> > Any thoughts on this?
> >
> >
> > Thanks,
> >
> > Ritesh
> >
> > ________________________________
> > From: Ritesh Garg <ritesh.garg(a)outlook.com>
> > Sent: Thursday, January 19, 2017 9:47 AM
> > To: keycloak-dev(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Best regards,
Konstantin Gribov
7:20 a.m.
Yes, I totally agree. I'm not a OP, though. Maybe he has some other use
case where he think he need impersonation.
I've just explained a workaroud I have in use case where I *could* think
impersonation would be way to go because it's hard to integrate offline
tokens in my case.
But I'm totally aware that such feature shouldn't be implemented because of
its security implications.
ср, 25 янв. 2017 г. в 15:31, Stian Thorgersen <sthorger(a)redhat.com>:
On 25 January 2017 at 13:24, Konstantin Gribov
<grossws(a)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(a)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(a)outlook.com> wrote:
> Hello,
>
>
> Any thoughts on this?
>
>
> Thanks,
>
> Ritesh
>
> ________________________________
> From: Ritesh Garg <ritesh.garg(a)outlook.com>
> Sent: Thursday, January 19, 2017 9:47 AM
> To: keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Best regards,
Konstantin Gribov
--
Best regards,
Konstantin Gribov
7:25 p.m.
Apologies for the late reply. My use case was similar to what Gribov mentioned. I agree,
offline tokens approach is the right approach to achieve that. Feel free to reject the
issue in Jira. Thank you.
________________________________
From: Konstantin Gribov <grossws(a)gmail.com>
Sent: Wednesday, January 25, 2017 8:20 AM
To: stian(a)redhat.com
Cc: Ritesh Garg; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Keycloak Impersonation feature | KEYCLOAK-4219
Yes, I totally agree. I'm not a OP, though. Maybe he has some other use case where he
think he need impersonation.
I've just explained a workaroud I have in use case where I *could* think impersonation
would be way to go because it's hard to integrate offline tokens in my case.
But I'm totally aware that such feature shouldn't be implemented because of its
security implications.
ср, 25 янв. 2017 г. в 15:31, Stian Thorgersen
<sthorger@redhat.com<mailto:sthorger@redhat.com>>:
On 25 January 2017 at 13:24, Konstantin Gribov
<grossws@gmail.com<mailto:grossws@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@redhat.com<mailto:sthorger@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@outlook.com<mailto:ritesh.garg@outlook.com>> wrote:
Hello,
Any thoughts on this?
Thanks,
Ritesh
________________________________
From: Ritesh Garg <ritesh.garg@outlook.com<mailto:ritesh.garg@outlook.com>>
Sent: Thursday, January 19, 2017 9:47 AM
To: keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Best regards,
Konstantin Gribov
--
Best regards,
Konstantin Gribov
3234
days inactive
3281
days old
6 comments
3 participants
participants (3)
-
Konstantin Gribov -
Ritesh Garg -
Stian Thorgersen