You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Thorsten Höger <li...@hoegernet.de> on 2012/10/08 15:34:08 UTC
Using OAuth 2.0
Hi,
after using the OAuth 2.0 implementation for a while now I wanted to
give some feedback.
In general I really like the implementation and it works very well.
The support for ResourceOwnerAuth and the RefreshToken are very nice.
There are only two features I was missing:
1) In the AuthorizationCodeGrantService there are two private methods
using sessions to store and retrieve the sessionAuthenticityToken. It
would be nice to be able to change the storage.
I had to create a deep copy of this class to use some other session store.
2) I found no way to get the Bearer token and the authorized client via
the injected MessageContext. I copied the OAuthRequestFilter and put the
AccessTokenValidation into the message which worked perfectly. May be
this could be done by default.
Regards,
Thorsten Höger
Re: Using OAuth 2.0
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi - many thanks for the patches - they look good, I will apply asap, I
just need to fix a couple of older bugs first :-)
Cheers, Sergey
On 09/10/12 10:43, Thorsten Höger wrote:
> Am 09.10.2012 11:04, schrieb Sergey Beryozkin:
>> Hi,
>>
>> On 09/10/12 09:22, Thorsten Höger wrote:
>>> Hi,
>>>
>>>
>>> Am 08.10.2012 23:01, schrieb Sergey Beryozkin:
>>>> Hi Thorsten,
>>>>
>>>> thanks for the valuable feedback,
>>>>
>>>> On 08/10/12 14:34, Thorsten Höger wrote:
>>>>> Hi,
>>>>>
>>>>> after using the OAuth 2.0 implementation for a while now I wanted to
>>>>> give some feedback.
>>>>>
>>>>> In general I really like the implementation and it works very well.
>>>>> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>>>>>
>>>>> There are only two features I was missing:
>>>>>
>>>>> 1) In the AuthorizationCodeGrantService there are two private methods
>>>>> using sessions to store and retrieve the sessionAuthenticityToken. It
>>>>> would be nice to be able to change the storage.
>>>>> I had to create a deep copy of this class to use some other session
>>>>> store.
>>>>
>>>> Yes, please provide a patch if you can, I guess we can also consider
>>>> introducing a simple interface for keeping the user session token, the
>>>> runtime will delegate to it if a custom implementation has been
>>>> registered
>>>>
>>>
>>> I created the follwoing JIRA tickets and will provide patches soon.
>>> CXF-4548 and CXF-4549
>>
>> thanks...
>>
>>>
>>>
>>>>>
>>>>> 2) I found no way to get the Bearer token and the authorized client
>>>>> via
>>>>> the injected MessageContext. I copied the OAuthRequestFilter and
>>>>> put the
>>>>> AccessTokenValidation into the message which worked perfectly. May be
>>>>> this could be done by default.
>>>>>
>>>> What exactly do you need from the token ? The filter does
>>>>
>>>> m.setContent(OAuthContext.class, new
>>>> OAuthContext(accessTokenV.getTokenSubject(),
>>>>
>>>> matchingPermissions,
>>>>
>>>> accessTokenV.getTokenGrantType()));
>>>>
>>>> so messageContext.getContext(OAuthContext.class) will return it, with
>>>>
>>>> accessTokenV.getTokenSubject() representing an authenticated client,
>>>> and accessTokenV.getTokenGrantType() - the grant type.
>>>>
>>>> I guess all the token can be made available on the current message,
>>>> but I was not sure how much more of the token details the application
>>>> code may need to know...
>>>>
>>>> Cheers, Sergey
>>>
>>> It would be nice to get the Bearer token itself to provide token
>>> invalidation functionality and with the subject I can only get the
>>> authorized user but in some cases I need the requesting client which has
>>> the user token.
>>> I want to limit access to some clients (eg only website not apps)
>>
>> Indeed, it is actually the authorized user which is currently
>> available, not the client, I got confused a bit yesterday :-).
>>
>> The information about the client (its id and subject) is only used to
>> set the active SecurityContext for the purpose of using the
>> 'isUserInRole' kind of authorization. Note, the client subject may
>> contain the roles (assuming CXF JAASLoginInInterceptor was used to get
>> the client authenticated during it requesting the token) - so in
>> principle, the additional client restrictions can be enforced with the
>> use of RBAC. However I do agree that having a client info available on
>> the message would be useful too.
>>
>> Note, I was originally thinking of keeping AccessTokenValidation
>> 'internal' to the filter, so that it can do the additional
>> verification in addition to the registered AccessTokenValidator,
>> specifically, it filters the token permissions against the current URI
>> path and HTTP verb, and it is actually the intersected set of
>> permissions that 'makes' it into OAuthContext - which is meant to
>> represent all the info about the requesting client the application
>> code may need to know for doing some custom validation/checks.
>>
>> Would you be OK with expanding OAuthContext instead of making
>> AccessTokenValidation available to the application ? This involves a
>> bit of duplication, but I'm thinking this will let us experiment more
>> later on with the way the access tokens can get validated without
>> affecting the application code...
>>
>> Cheers, Sergey
>
> I just submitted a first patch with AccessTokenValidation but the other
> solution is fine too. But it would be nice to have ClientID and Token
> available in OAuthContext if you go this way.
>
> Thanks, Thorsten
>
> PS: Maybe we can discuss this on the ticket for better history
>>
>>
Re: Using OAuth 2.0
Posted by Thorsten Höger <li...@hoegernet.de>.
Am 09.10.2012 11:04, schrieb Sergey Beryozkin:
> Hi,
>
> On 09/10/12 09:22, Thorsten Höger wrote:
>> Hi,
>>
>>
>> Am 08.10.2012 23:01, schrieb Sergey Beryozkin:
>>> Hi Thorsten,
>>>
>>> thanks for the valuable feedback,
>>>
>>> On 08/10/12 14:34, Thorsten Höger wrote:
>>>> Hi,
>>>>
>>>> after using the OAuth 2.0 implementation for a while now I wanted to
>>>> give some feedback.
>>>>
>>>> In general I really like the implementation and it works very well.
>>>> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>>>>
>>>> There are only two features I was missing:
>>>>
>>>> 1) In the AuthorizationCodeGrantService there are two private methods
>>>> using sessions to store and retrieve the sessionAuthenticityToken. It
>>>> would be nice to be able to change the storage.
>>>> I had to create a deep copy of this class to use some other session
>>>> store.
>>>
>>> Yes, please provide a patch if you can, I guess we can also consider
>>> introducing a simple interface for keeping the user session token, the
>>> runtime will delegate to it if a custom implementation has been
>>> registered
>>>
>>
>> I created the follwoing JIRA tickets and will provide patches soon.
>> CXF-4548 and CXF-4549
>
> thanks...
>
>>
>>
>>>>
>>>> 2) I found no way to get the Bearer token and the authorized client
>>>> via
>>>> the injected MessageContext. I copied the OAuthRequestFilter and
>>>> put the
>>>> AccessTokenValidation into the message which worked perfectly. May be
>>>> this could be done by default.
>>>>
>>> What exactly do you need from the token ? The filter does
>>>
>>> m.setContent(OAuthContext.class, new
>>> OAuthContext(accessTokenV.getTokenSubject(),
>>>
>>> matchingPermissions,
>>>
>>> accessTokenV.getTokenGrantType()));
>>>
>>> so messageContext.getContext(OAuthContext.class) will return it, with
>>>
>>> accessTokenV.getTokenSubject() representing an authenticated client,
>>> and accessTokenV.getTokenGrantType() - the grant type.
>>>
>>> I guess all the token can be made available on the current message,
>>> but I was not sure how much more of the token details the application
>>> code may need to know...
>>>
>>> Cheers, Sergey
>>
>> It would be nice to get the Bearer token itself to provide token
>> invalidation functionality and with the subject I can only get the
>> authorized user but in some cases I need the requesting client which has
>> the user token.
>> I want to limit access to some clients (eg only website not apps)
>
> Indeed, it is actually the authorized user which is currently
> available, not the client, I got confused a bit yesterday :-).
>
> The information about the client (its id and subject) is only used to
> set the active SecurityContext for the purpose of using the
> 'isUserInRole' kind of authorization. Note, the client subject may
> contain the roles (assuming CXF JAASLoginInInterceptor was used to get
> the client authenticated during it requesting the token) - so in
> principle, the additional client restrictions can be enforced with the
> use of RBAC. However I do agree that having a client info available on
> the message would be useful too.
>
> Note, I was originally thinking of keeping AccessTokenValidation
> 'internal' to the filter, so that it can do the additional
> verification in addition to the registered AccessTokenValidator,
> specifically, it filters the token permissions against the current URI
> path and HTTP verb, and it is actually the intersected set of
> permissions that 'makes' it into OAuthContext - which is meant to
> represent all the info about the requesting client the application
> code may need to know for doing some custom validation/checks.
>
> Would you be OK with expanding OAuthContext instead of making
> AccessTokenValidation available to the application ? This involves a
> bit of duplication, but I'm thinking this will let us experiment more
> later on with the way the access tokens can get validated without
> affecting the application code...
>
> Cheers, Sergey
I just submitted a first patch with AccessTokenValidation but the other
solution is fine too. But it would be nice to have ClientID and Token
available in OAuthContext if you go this way.
Thanks, Thorsten
PS: Maybe we can discuss this on the ticket for better history
>
>
>
>
>
>
>
>
>>>
>>>> Regards,
>>>>
>>>> Thorsten Höger
>>>
>>>
>>
>
>
Re: Using OAuth 2.0
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 09/10/12 09:22, Thorsten Höger wrote:
> Hi,
>
>
> Am 08.10.2012 23:01, schrieb Sergey Beryozkin:
>> Hi Thorsten,
>>
>> thanks for the valuable feedback,
>>
>> On 08/10/12 14:34, Thorsten Höger wrote:
>>> Hi,
>>>
>>> after using the OAuth 2.0 implementation for a while now I wanted to
>>> give some feedback.
>>>
>>> In general I really like the implementation and it works very well.
>>> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>>>
>>> There are only two features I was missing:
>>>
>>> 1) In the AuthorizationCodeGrantService there are two private methods
>>> using sessions to store and retrieve the sessionAuthenticityToken. It
>>> would be nice to be able to change the storage.
>>> I had to create a deep copy of this class to use some other session
>>> store.
>>
>> Yes, please provide a patch if you can, I guess we can also consider
>> introducing a simple interface for keeping the user session token, the
>> runtime will delegate to it if a custom implementation has been
>> registered
>>
>
> I created the follwoing JIRA tickets and will provide patches soon.
> CXF-4548 and CXF-4549
thanks...
>
>
>>>
>>> 2) I found no way to get the Bearer token and the authorized client via
>>> the injected MessageContext. I copied the OAuthRequestFilter and put the
>>> AccessTokenValidation into the message which worked perfectly. May be
>>> this could be done by default.
>>>
>> What exactly do you need from the token ? The filter does
>>
>> m.setContent(OAuthContext.class, new
>> OAuthContext(accessTokenV.getTokenSubject(),
>>
>> matchingPermissions,
>>
>> accessTokenV.getTokenGrantType()));
>>
>> so messageContext.getContext(OAuthContext.class) will return it, with
>>
>> accessTokenV.getTokenSubject() representing an authenticated client,
>> and accessTokenV.getTokenGrantType() - the grant type.
>>
>> I guess all the token can be made available on the current message,
>> but I was not sure how much more of the token details the application
>> code may need to know...
>>
>> Cheers, Sergey
>
> It would be nice to get the Bearer token itself to provide token
> invalidation functionality and with the subject I can only get the
> authorized user but in some cases I need the requesting client which has
> the user token.
> I want to limit access to some clients (eg only website not apps)
Indeed, it is actually the authorized user which is currently available,
not the client, I got confused a bit yesterday :-).
The information about the client (its id and subject) is only used to
set the active SecurityContext for the purpose of using the
'isUserInRole' kind of authorization. Note, the client subject may
contain the roles (assuming CXF JAASLoginInInterceptor was used to get
the client authenticated during it requesting the token) - so in
principle, the additional client restrictions can be enforced with the
use of RBAC. However I do agree that having a client info available on
the message would be useful too.
Note, I was originally thinking of keeping AccessTokenValidation
'internal' to the filter, so that it can do the additional verification
in addition to the registered AccessTokenValidator, specifically, it
filters the token permissions against the current URI path and HTTP
verb, and it is actually the intersected set of permissions that 'makes'
it into OAuthContext - which is meant to represent all the info about
the requesting client the application code may need to know for doing
some custom validation/checks.
Would you be OK with expanding OAuthContext instead of making
AccessTokenValidation available to the application ? This involves a bit
of duplication, but I'm thinking this will let us experiment more later
on with the way the access tokens can get validated without affecting
the application code...
Cheers, Sergey
>>
>>> Regards,
>>>
>>> Thorsten Höger
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Using OAuth 2.0
Posted by Thorsten Höger <li...@hoegernet.de>.
Hi,
Am 08.10.2012 23:01, schrieb Sergey Beryozkin:
> Hi Thorsten,
>
> thanks for the valuable feedback,
>
> On 08/10/12 14:34, Thorsten Höger wrote:
>> Hi,
>>
>> after using the OAuth 2.0 implementation for a while now I wanted to
>> give some feedback.
>>
>> In general I really like the implementation and it works very well.
>> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>>
>> There are only two features I was missing:
>>
>> 1) In the AuthorizationCodeGrantService there are two private methods
>> using sessions to store and retrieve the sessionAuthenticityToken. It
>> would be nice to be able to change the storage.
>> I had to create a deep copy of this class to use some other session
>> store.
>
> Yes, please provide a patch if you can, I guess we can also consider
> introducing a simple interface for keeping the user session token, the
> runtime will delegate to it if a custom implementation has been
> registered
>
I created the follwoing JIRA tickets and will provide patches soon.
CXF-4548 and CXF-4549
>>
>> 2) I found no way to get the Bearer token and the authorized client via
>> the injected MessageContext. I copied the OAuthRequestFilter and put the
>> AccessTokenValidation into the message which worked perfectly. May be
>> this could be done by default.
>>
> What exactly do you need from the token ? The filter does
>
> m.setContent(OAuthContext.class, new
> OAuthContext(accessTokenV.getTokenSubject(),
>
> matchingPermissions,
>
> accessTokenV.getTokenGrantType()));
>
> so messageContext.getContext(OAuthContext.class) will return it, with
>
> accessTokenV.getTokenSubject() representing an authenticated client,
> and accessTokenV.getTokenGrantType() - the grant type.
>
> I guess all the token can be made available on the current message,
> but I was not sure how much more of the token details the application
> code may need to know...
>
> Cheers, Sergey
It would be nice to get the Bearer token itself to provide token
invalidation functionality and with the subject I can only get the
authorized user but in some cases I need the requesting client which has
the user token.
I want to limit access to some clients (eg only website not apps)
>
>> Regards,
>>
>> Thorsten Höger
>
>
Re: Using OAuth 2.0
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Thorsten,
thanks for the valuable feedback,
On 08/10/12 14:34, Thorsten Höger wrote:
> Hi,
>
> after using the OAuth 2.0 implementation for a while now I wanted to
> give some feedback.
>
> In general I really like the implementation and it works very well.
> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>
> There are only two features I was missing:
>
> 1) In the AuthorizationCodeGrantService there are two private methods
> using sessions to store and retrieve the sessionAuthenticityToken. It
> would be nice to be able to change the storage.
> I had to create a deep copy of this class to use some other session store.
Yes, please provide a patch if you can, I guess we can also consider
introducing a simple interface for keeping the user session token, the
runtime will delegate to it if a custom implementation has been registered
>
> 2) I found no way to get the Bearer token and the authorized client via
> the injected MessageContext. I copied the OAuthRequestFilter and put the
> AccessTokenValidation into the message which worked perfectly. May be
> this could be done by default.
>
What exactly do you need from the token ? The filter does
m.setContent(OAuthContext.class, new
OAuthContext(accessTokenV.getTokenSubject(),
matchingPermissions,
accessTokenV.getTokenGrantType()));
so messageContext.getContext(OAuthContext.class) will return it, with
accessTokenV.getTokenSubject() representing an authenticated client, and
accessTokenV.getTokenGrantType() - the grant type.
I guess all the token can be made available on the current message, but
I was not sure how much more of the token details the application code
may need to know...
Cheers, Sergey
> Regards,
>
> Thorsten Höger
Re: Using OAuth 2.0
Posted by Thorsten Höger <li...@hoegernet.de>.
Hi,
I will create a JIRA ticket and try to provide a patch.
Thanks,
Thorsten
Am 08.10.2012 22:12, schrieb Daniel Kulp:
> On Oct 8, 2012, at 9:34 AM, Thorsten Höger <li...@hoegernet.de> wrote:
>
>> Hi,
>>
>> after using the OAuth 2.0 implementation for a while now I wanted to
>> give some feedback.
>>
>> In general I really like the implementation and it works very well.
>> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>>
>> There are only two features I was missing:
>>
>> 1) In the AuthorizationCodeGrantService there are two private methods
>> using sessions to store and retrieve the sessionAuthenticityToken. It
>> would be nice to be able to change the storage.
>> I had to create a deep copy of this class to use some other session store.
> There's likely a bunch of places where things could be marked protected to help make things more usable from subclasses. Patches toward those goals are usually accepted fairly quickly. These are the types of things that are generally better to be done by someone actually creating the subclass as it's sometimes hard for us to really see where someone may need an extension point. Definitely create a JIRA issue and supply a patch if you can.
>
> Dan
>
>
>
>> 2) I found no way to get the Bearer token and the authorized client via
>> the injected MessageContext. I copied the OAuthRequestFilter and put the
>> AccessTokenValidation into the message which worked perfectly. May be
>> this could be done by default.
>>
>> Regards,
>>
>> Thorsten Höger
Re: Using OAuth 2.0
Posted by Daniel Kulp <dk...@apache.org>.
On Oct 8, 2012, at 9:34 AM, Thorsten Höger <li...@hoegernet.de> wrote:
> Hi,
>
> after using the OAuth 2.0 implementation for a while now I wanted to
> give some feedback.
>
> In general I really like the implementation and it works very well.
> The support for ResourceOwnerAuth and the RefreshToken are very nice.
>
> There are only two features I was missing:
>
> 1) In the AuthorizationCodeGrantService there are two private methods
> using sessions to store and retrieve the sessionAuthenticityToken. It
> would be nice to be able to change the storage.
> I had to create a deep copy of this class to use some other session store.
There's likely a bunch of places where things could be marked protected to help make things more usable from subclasses. Patches toward those goals are usually accepted fairly quickly. These are the types of things that are generally better to be done by someone actually creating the subclass as it's sometimes hard for us to really see where someone may need an extension point. Definitely create a JIRA issue and supply a patch if you can.
Dan
> 2) I found no way to get the Bearer token and the authorized client via
> the injected MessageContext. I copied the OAuthRequestFilter and put the
> AccessTokenValidation into the message which worked perfectly. May be
> this could be done by default.
>
> Regards,
>
> Thorsten Höger
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com