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
