cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Wang <>
Subject 2.5 and OAuth
Date Wed, 09 Nov 2011 02:16:38 GMT
With great anticipation, I am looking through the OAuth 1.0
implementation in CXF.  I have some questions:
In AuthorizationRequestService

1) This is just authorization, right?  So we actually need to have
secured the (in the example) /forms/oauthAuthorize.jsp so that before
they go there, they are authenticated as a user of myapp?

In Protecting resources with OAuth filters,
Bullet point 2, "It will check if Client and AccessToken have a "uris"
property set and if yes then it will validate the current request URI
against it."

1) the list of URIs with the client is the client's app, right?
( - the javadoc says it could be used to
check the callback URL) So the current URI
( will always fail? (the Token's
scope and uri is fine, because it is set at the time /initiate is
2) Is matching a wildcard match?  for example (myapp/user/*/profile
myapp/user/{userId}/contacts) if I want to allow a user to see the
profile of all their contacts, but not their contacts' contacts.

the bullet point 4, "Finally, it will create a SecurityContext using
this list of OAuthPermissions and the Client loginName property."

1) Since we're talking about SecurityContext, that means this is
Spring Security, right?

2) Since the client (which is a representation of the consumer,
right?) is authenticated on behalf of the end user, shouldn't the
Authentication object represent the user detail of the end user?

3) Speaking of which, could we configure a custom UserDetailService?

4) Is there a way to protect different endpoints on the same
jaxrs:server declaration with different scopes? for example, different
scopes for GET /myapp/user/{userId}/profile and GET

5) If I want to make sure that only {userId} have access to their
/user/{userId}/super-secret-information, is it possible to make sure
that the end-user being authenticated is the same one that is
authorized? or do I have to check it in the getSuperSecretInformation
method via the SecurityContextHolder?

Thanks, and I look forward to using this new feature!

View raw message