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