Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.214.41 as permitted sender)
Message-ID: <50753E53.1070804@gmail.com>
Date: Wed, 10 Oct 2012 10:22:27 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Using OAuth 2.0
References: <5072D650.2010403@hoegernet.de> <50733F1A.6060503@gmail.com>
 <5073DEE2.5090003@hoegernet.de> <5073E896.6000804@gmail.com>
 <5073F1B9.1020605@hoegernet.de>
In-Reply-To: <5073F1B9.1020605@hoegernet.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

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
>>
>>