Hi
On 04/10/12 21:33, gbmamat wrote:
To understand the CXF implementation of OAuth2 specification, I propose to
implement the case study described below.
Use case
Subject: The objective is to secure access to the RESTFul resource
PayGateway described by the table below.
Opération Path HTTP Verbs
Permission(Scope)
findAllAccounts /account GET
manage_accounts
findAccount /account/find GET
manage_accounts
createAccount /account/create POST
manage_accounts
modifyAccount /account/modify PUT
manage_accounts
deleteAccount /account/delete DELETE
manage_accounts
getAccountBalance /account/balance GET
view_balance
findAllCheckout /checkout GET
collect_payments
findCheckout /checkout/find GET
collect_payments
createCheckout /checkout/create POST
collect_payments
cancelCheckout /checkout/cancel POST
collect_payments
captureCheckout /checkout/capture POST
collect_payments
refundCheckout /checkout/refund POST
refund_payments
RESTFul Resource implementation class
org.apache.cxf.rs.security.oauth2.services.PayGateway
OAuthDataProvider implementation
org.apache.cxf.rs.security.oauth2.provider.JdbcOAuthDataProvider implements
org.apache.cxf.rs.security.oauth2.provider.OAuthDataProvider
My Oauth2.0 server implementation proposal
//OAuth2 Server services as independencies endpoints
<bean id="oauthProvider" class="
org.apache.cxf.rs.security.oauth2.provider.JdbcOAuthDataProvider"/>
<bean id="accessTokenService"
class="org.apache.cxf.rs.security.oauth2.services.AccessTokenService">
<property name="dataProvider" ref="oauthProvider"/>
</bean>
<bean id="accessTokenValidateService"
class="org.apache.cxf.rs.security.oauth2.services.AccessTokenValidateService">
<property name="dataProvider" ref="oauthProvider"/>
</bean>
<bean id="authorizationService"
class="org.apache.cxf.rs.security.oauth2.services.AuthorizationCodeGrantService">
<property name="dataProvider" ref="oauthProvider"/>
</bean>
<jaxrs:server id="oauthServer" address="/oauth">
<jaxrs:serviceBeans>
<ref bean="accessTokenService"/>
<ref bean="accessTokenValidateService"/>
<ref bean="authorizationService"/>
</jaxrs:serviceBeans>
</jaxrs:server>
//Restful resource services spring configuration
<bean id="tvServiceClientFactory"
class="org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean">
<property name="address"
value="http://localhost:${http.port}/services/oauth/validate"/>
<property name="headers">
<map>
<entry key="Accept" value="application/xml"/>
<entry key="Accept" value="application/json"/>
</map>
</property>
</bean>
<bean id="tvServiceClient"
factory-bean="tvServiceClientFactory"
factory-method="createWebClient"/>
<bean id="tokenValidator"
class="org.apache.cxf.rs.security.oauth2.filters.AccessTokenValidatorClient">
<property name="tokenValidatorClient" ref="tvServiceClient"/>
</bean>
<bean id="oauthFiler"
class="org.apache.cxf.rs.security.oauth2.filters.OAuthRequestFilter">
<property name="tokenValidator" ref="tokenValidator"/>
</bean>
<bean id="payGateway"
class="org.apache.cxf.rs.security.oauth2.services.PayGateway"/>
<jaxrs:server id="payGatewayResource" address="/paygateway">
<jaxrs:serviceBeans>
<ref bean="payGateway"/>
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="oauthFilter"/>
</jaxrs:providers>
</jaxrs:server>
Few notes re the above configuration.
Registering AccessTokenValidatorService is important only if you already
have a case where an application server and OAuth AS server are running
on different ports/machines - I guess this is likely to be the more
realistic scenario in productions, but you can definitely avoid it in
simpler demo-like or POC cases - in that case 'oauthFilter' can be
linked with the 'oauthProvider' directly.
I'm assuming you are interested in supporting an authorization code
flow, right ? If yes then you need to get AuthorizationCodeDataProvider
implemented (extends OAuthDataProvider) because it has an extra
responsibility (unique to the flow) to persist the grant (in db or
memory - as discussed in the previous two emails) and then remove it
when it is requested.
Finally, having a single JAX-RS endpoint assumes that you'd like the end
user and a 3rd party client see the common URI space, i.e, access
PayGateway service using the same URI paths. That complicates things a
bit because at the security enforcement level you have to distinguish
between OAuth (from 3rd party clients) and regular end user requests
which will likely be authenticated with some other mechanisms.
If you'd like to pursue this path then extend
org.apache.cxf.rs.security.oauth2.filters.OAuthRequestFilter, check the
Authorization scheme, if it is 'Bearer' or whatever OAuth token scheme
you use, say 'MAC', then assume it is a 3rd party client and delegate to
the superclass, otherwise attempt to authenticate a regular user - for
the latter reusing JAASLoginInterceptor can be handy.
A simpler approach is to offer one more endpoint - limited to supporting
a 3rd party client view only, by having a simple wrapper bean of the
original 'payGateway' bean and providing only those few resource methods
which are meaningful for a 3rd party client - this way you can configure
the original 'payGateway' to authenticate the end users only using
whatever mechanism you prefer, but limit this another endpoint to
getting only OAuth clients authenticated.
I've tried to put it into Design Considerations section...
What do you propose to manage permissions (Scope) flexibly?
Well, I guess it is all about the down-scoping. The client may request a
'manage_accounts, collect_payments' composite scope but a user has to be
offered a chance to limit it to say "collect_payments" only.
Have a look at
https://github.com/Talend/tesb-rt-se/tree/master/examples/cxf/jaxrs-oauth2
The down-scoping is demonstrated there, plus the idea of having two
different views (one for end users, one for clients)
HTH, Sergey
Can you approve my proposal for implementation of the following layers:
OAuth2 Services layer and Restful API Resource layer?
Thank you in advance.
Regards,
Ghislain
--
View this message in context:
http://cxf.547215.n5.nabble.com/Using-Database-to-store-OAuth2-0-server-informations-tp5715521p5715690.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
