You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by gbmamat <gh...@gbm-systems.com> on 2012/10/03 16:05:35 UTC
Using Database to store OAuth2.0 server informations.
Hi,
Please, what are the persistent objects if you want to store in a database
all OAuth2.0 server information?
In fact, I want to create a JDBC implementation of
AuthorizationCodeDataProvider interface.
Regards,
Ghislain
--
View this message in context: http://cxf.547215.n5.nabble.com/Using-Database-to-store-OAuth2-0-server-informations-tp5715521.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Using Database to store OAuth2.0 server informations.
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
Re: Using Database to store OAuth2.0 server informations.
Posted by gbmamat <gh...@gbm-systems.com>.
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>
What do you propose to manage permissions (Scope) flexibly?
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.
Re: Using Database to store OAuth2.0 server informations.
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ghislain
On 03/10/12 16:21, gbmamat wrote:
> Hi Sergey,
>
> Thank you for your answer.
>
> I think it is indisponsable persist following data:
>
> -Client: This table can be customize and adapt depending on the model
> customer data
> -ServerAccessToken
> -OAuthPermission
> -User
> -Role
>
> these data are not temporary. Indeed, if they are not persisted, it will be
> lost after reboot server OAuth2, plus you can not update its data (eg adding
> a new scope, adding dynamic client, ...) without reloading the OAuth2
> server.
Sure, I was really referring to the info which captures the agreement
from the user (effectively a grant), the storage of which can be
optimized. That really depends on the application - if it is important
that a user grant survives the restart then it has to be persisted,
otherwise, perhaps it makes sense to get a client to re-authorize if it
waited too long for attempting to exchange a grant for a token, too long
a period might indicate a security concern...
Sergey
>
> What do you think?
>
> Regards,
>
> Ghislain
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Using-Database-to-store-OAuth2-0-server-informations-tp5715521p5715540.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
Re: Using Database to store OAuth2.0 server informations.
Posted by gbmamat <gh...@gbm-systems.com>.
Hi Sergey,
Thank you for your answer.
I think it is indisponsable persist following data:
-Client: This table can be customize and adapt depending on the model
customer data
-ServerAccessToken
-OAuthPermission
-User
-Role
these data are not temporary. Indeed, if they are not persisted, it will be
lost after reboot server OAuth2, plus you can not update its data (eg adding
a new scope, adding dynamic client, ...) without reloading the OAuth2
server.
What do you think?
Regards,
Ghislain
--
View this message in context: http://cxf.547215.n5.nabble.com/Using-Database-to-store-OAuth2-0-server-informations-tp5715521p5715540.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Using Database to store OAuth2.0 server informations.
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ghislain
thanks for redirecting the question to users list,
On 03/10/12 15:05, gbmamat wrote:
> Hi,
>
> Please, what are the persistent objects if you want to store in a database
> all OAuth2.0 server information?
>
Typically, these are Client and ServerAccessToken which can have some
sub objects. Please note these are model classes only, they are the
'bridge' between the runtime and whatever persistence layer the
application has chosen to persist the actual data in, and thus do not
necessarily to be persisted 'as is'
> In fact, I want to create a JDBC implementation of
> AuthorizationCodeDataProvider interface.
>
Authorization code provider extends the data provider as it needs to
keep the transient user authorization confirmation details up until the
client requests a token in exchange for a grant. I guess one option is
to keep them in memory, using ehcache may be (to manage possible
overflows, etc) given that this data is supposed to be short-lived...
Though trying with JDBC should be a good start.
Let me know if you'd like to get more info,
Cheers, Sergey
>
> Regards,
>
> Ghislain
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Using-Database-to-store-OAuth2-0-server-informations-tp5715521.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