cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: [GSoC][OAUTH] OAuth configuration in cxf
Date Mon, 07 Jun 2010 13:05:27 GMT
Hi

On Mon, Jun 7, 2010 at 12:47 AM, Łukasz Moreń <lukasz.moren@gmail.com>wrote:

> I was thinking about how to configure oauth authentication in cxf,
> below are my thoughts and doubts:
>
> 1. Oauth service provider needs to expose endpoint URLs for clients:
> Request Token URL, User Authorization URL and Access Token URL where
> client get request tokens and exchange request tokens for access
> tokens .
> How developers should define this endpoints?
>
> The first idea is to use servlet to handle issuing and exchanging
> tokens, and servlet context-params to define endpoint URLs:
>
> <servlet-mapping>
>  <servlet-name>OAuthTokenService</servlet-name>
>  <url-pattern>/oauth/*</url-pattern>
> </servlet-mapping>
>
> <context-param>
>   <param-name>requestTokenURL</param-name>
>   <param-value>/requestToken</param-value>
> </context-param>
>
> so i.e. client requests oauth request token at URL:
> http://www.domain.com/oauth/requestToken (respectively for other
> endpoints).
>
> The second one is to use jaxrs without annotations approach and have
> entry in beans.xml similar to:
>
>    <model xmlns="http://cxf.apache.org/jaxrs">
>        <resource name="org.apache.cxf.auth.oauth.RequestTokenService"
> path="/oauth/requestTokenURL">
>            <operation name="getRequestToken" verb="GET" />
>        </resource>
>         ....
>        (respectively for other endpoints).
>    </model>
>
> <operation name /> can be even omitted, and be configured through
> annotations.
>
> I like most second.
>
>
I'd go for option 2 too initially, but I'd not be concerned about
introducing a user model just yet. The main idea behind using user models is
to let users avoid adding JAXRS annotations in cases where it does not seem
practical or ideal or just help users who are just not keen on using
annotations... Please feel free to start with a user model if you wish, but
I'd just go for a JAXRS annotated resource initially and then add a user
model as an option for users to try.

That said, we have to bear in mind some users won't use Spring - we can have
an OAuth servlet extending CXFNonSpringJAXRSServlet too as another option
but this servlet will just bootstrap the OAuth resource and providers if
any...


> 2. How to define which protected resources/jaxrs services require
> OAuth authentication and how to handle authentication process?
> I think we could register kind of oauthAuthenticationProvider (that
> handle authentication process) for every service that requires OAuth
> i.e.:
>
> <bean id="oauthAuthenticationProvider"
> class="org.apache.cxf.auth.oauth.providers.OAuthAuthenticationProvider">
>
>  <jaxrs:server id="customerService" address="/service1">
>    <jaxrs:serviceBeans>
>      <ref bean="customerBean" />
>    </jaxrs:serviceBeans>
>
>    <jaxrs:providers>
>             <ref bean="oauthAuthenticationProvider" />
>    </jaxrs:providers>
>  </jaxrs:server>
>
> I'd probably go with this option initially, it is easier to configure the
provider this way


> or add attribute oauthSecured: <jaxrs:server id="customerService"
> address="/service1" oauthSecured="true">,
> so OAuthAuthenticationProvider is register automatically.
>
> or use java filter and filter mapping to intercept and handle OAuth
> authentication.
>

using filter is also an option which would be especially useful when no
Spring is used. But this filter would just be able to reuse this provider's
code anyway  -  so if users use Spring but can not or wish to update their
spring configs with references to oauth provider beans then using a filter
would be another option.


> I was thinking also about annotation that specify secured resources
> i.e. @OAuthSecured, but I'm not sure if it is good approach.
>
> Not sure about it. Ideally we'd just use filters/providers or add the
existing security-related  annotations (Spring based, java security based,
etc)

Perhaps all described configuration ways can be used with better or
> worse effect, but I would like to hear WDYT?
> I hope it makes sense what I wrote:)
>

it does :-)

thanks, Sergey


>
> Thanks.
>
> Cheers
> Lukasz Moren
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message