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
