You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by inteloid <ha...@gmail.com> on 2013/06/17 14:05:23 UTC
OAuth2 for redundant CXF REST Services
Hello.
We have multiple redundant instances of Apache CXF REST Services hidden
behind a ballancer, and we need to integrate OAuth2.
Everything works as needed with a single machine, the problem is, where to
persist server access tokens for retrieval from another CXF machine? What
are the best practices here in terms of serialization and storage types?
--
View this message in context: http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: OAuth2 for redundant CXF REST Services
Posted by inteloid <ha...@gmail.com>.
Thanks again. I'm looking into that :-)
--
View this message in context: http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365p5729425.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: OAuth2 for redundant CXF REST Services
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 17/06/13 17:24, Sergey Beryozkin wrote:
> On 17/06/13 16:53, inteloid wrote:
>> Thank you Sergey, I really enjoy the speed you reply with :-).
>>
> may happen only when I have a vague idea of what I'm talking about :-)
>> For this case the if AccessTokenValidatorService holds instances of
>> ServerAccessToknes inside it's memory it becomes a single point of
>> failure,
>> so there's a need to persist the tokens somewhere.
>>
One thing I forgot to mention if AccessTokenValidatorService is used,
then the actual AccessTokenValidatorClient can get a fault-tolerant
WebClient injected, in fact it can use JMS transport if really needed
Sergey
> Sure. persist them in DB, with ehcache, etc, up to OAuthDataProvider, I
> was not suggesting they have to be kept in memory
>> To keep it simpler, isn't there a way to use the standard
>> OAuthRequestFilter
>> filter and implement a serializable ServerAccessToknes token which
>> will be
>> fetched and saved by OAuthDataProvider used by aforementioned filter?
> Yes, in the example I pointed you to the filter actually have no any
> knowledge of access tokens, what it gets from AccessTokenValidator is a
> JAXB beab, AccessTokenValidation - this is nearly a copy of
> ServerAccessToken. AccessTokenValidationService will return
> AccessTokenValidation over HTTP (by asking its data provider first),
>
> but as I said this is just one option: your custom AccessTokenValidator
> does not even have to use AccessTokenValidationService, you can employ a
> different mechanism for fetching the tokens from the remote locations
>
> Cheers, Sergey
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365p5729384.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: OAuth2 for redundant CXF REST Services
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 17/06/13 16:53, inteloid wrote:
> Thank you Sergey, I really enjoy the speed you reply with :-).
>
may happen only when I have a vague idea of what I'm talking about :-)
> For this case the if AccessTokenValidatorService holds instances of
> ServerAccessToknes inside it's memory it becomes a single point of failure,
> so there's a need to persist the tokens somewhere.
>
Sure. persist them in DB, with ehcache, etc, up to OAuthDataProvider, I
was not suggesting they have to be kept in memory
> To keep it simpler, isn't there a way to use the standard OAuthRequestFilter
> filter and implement a serializable ServerAccessToknes token which will be
> fetched and saved by OAuthDataProvider used by aforementioned filter?
Yes, in the example I pointed you to the filter actually have no any
knowledge of access tokens, what it gets from AccessTokenValidator is a
JAXB beab, AccessTokenValidation - this is nearly a copy of
ServerAccessToken. AccessTokenValidationService will return
AccessTokenValidation over HTTP (by asking its data provider first),
but as I said this is just one option: your custom AccessTokenValidator
does not even have to use AccessTokenValidationService, you can employ a
different mechanism for fetching the tokens from the remote locations
Cheers, Sergey
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365p5729384.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: OAuth2 for redundant CXF REST Services
Posted by inteloid <ha...@gmail.com>.
Thank you Sergey, I really enjoy the speed you reply with :-).
For this case the if AccessTokenValidatorService holds instances of
ServerAccessToknes inside it's memory it becomes a single point of failure,
so there's a need to persist the tokens somewhere.
To keep it simpler, isn't there a way to use the standard OAuthRequestFilter
filter and implement a serializable ServerAccessToknes token which will be
fetched and saved by OAuthDataProvider used by aforementioned filter?
--
View this message in context: http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365p5729384.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: OAuth2 for redundant CXF REST Services
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 17/06/13 13:05, inteloid wrote:
> Hello.
>
> We have multiple redundant instances of Apache CXF REST Services hidden
> behind a ballancer, and we need to integrate OAuth2.
>
> Everything works as needed with a single machine, the problem is, where to
> persist server access tokens for retrieval from another CXF machine? What
> are the best practices here in terms of serialization and storage types?
>
Have a look at
https://github.com/Talend/tesb-rt-se/blob/master/examples/cxf/jaxrs-oauth2/sso-saml/social-app-war/src/main/webapp/WEB-INF/thirdPartyToSocialApp.xml
here we have a custom application protected by OAuth2RequestFilter which
uses a custom AccessTokenValidator, in this case a client to
org.apache.cxf.rs.security.oauth2.services.AccessTokenValidatorService,
the latter (in the demo) is collocated with the remote
AccessTokenService so it has all the access to the token storage, etc.
This is one option and may not be exactly the best option, depends on
the requirements. You can have a custom AccessTokenValidator which will
fetch the tokens from the remote storage using some super-fast low-level
protocol, etc...Another option to try is to get access tokens encrypted
and have a custom AccessTokenValidator decrypting it and thus avoiding
any remote roundtrips...Perhaps we should offer some utility support for
the latter option
HTH, Sergey
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/OAuth2-for-redundant-CXF-REST-Services-tp5729365.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>