cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r812599 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth2.html
Date Thu, 12 Apr 2012 21:48:45 GMT
Author: buildbot
Date: Thu Apr 12 21:48:44 2012
New Revision: 812599

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/jax-rs-oauth2.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/jax-rs-oauth2.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-oauth2.html (original)
+++ websites/production/cxf/content/docs/jax-rs-oauth2.html Thu Apr 12 21:48:44 2012
@@ -125,11 +125,11 @@ Apache CXF -- JAX-RS OAuth2
 
 
 <div>
-<ul><li><a shape="rect" href="#JAX-RSOAuth2-Introduction">Introduction</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-Mavendependencies">Maven dependencies</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</a></li><ul><li><a
shape="rect" href="#JAX-RSOAuth2-AuthorizationService">Authorization Service</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-AccessTokenService">AccessTokenService</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-WritingOAuthDataProvider">Writing OAuthDataProvider</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-OAuthServerJAXRSendpoints">OAuth Server JAX-RS endpoints</a></li></ul><li><a
shape="rect" href="#JAX-RSOAuth2-ProtectingresourceswithOAuthfilters">Protecting resources
with OAuth filters</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Howtogettheuserloginname">How
to get the user login name</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Clientsidesupport">Client-side
support</a></li><li><a shape="r
 ect" href="#JAX-RSOAuth2-2legOAuthFlow">2-leg OAuth Flow</a></li><ul><li><a
shape="rect" href="#JAX-RSOAuth2-ClientrequestsPreAuthorizedRequestToken">Client requests
PreAuthorized RequestToken</a></li><li><a shape="rect" href="#JAX-RSOAuth2-SignaturewithConsumerKeyandSecret">Signature
with Consumer Key and Secret</a></li><li><a shape="rect" href="#JAX-RSOAuth2-OnlyConsumerKeyandSecretinAuthorizationheader">Only
Consumer Key and Secret in Authorization header</a></li></ul><li><a
shape="rect" href="#JAX-RSOAuth2-OAuthWithoutaBrowser">OAuth Without a Browser</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-Designconsiderations">Design considerations</a></li><ul><li><a
shape="rect" href="#JAX-RSOAuth2-ControllingtheAccesstoResourceServer">Controlling the
Access to Resource Server</a></li><ul><li><a shape="rect" href="#JAX-RSOAuth2-Sharingthesameaccesspathbetweenendusersandconsumers">Sharing
the same access path between end users and consumers</a></li><li><a shape="rect"
href="#JA
 X-RSOAuth2-Providingdifferentaccesspointstoendusersandconsumers">Providing different access
points to end users and consumers</a></li></ul><li><a shape="rect"
href="#JAX-RSOAuth2-SingleSignOn">Single Sign On</a></li></ul><li><a
shape="rect" href="#JAX-RSOAuth2-WhatIsNext">What Is Next</a></li></ul></div>
+<ul><li><a shape="rect" href="#JAX-RSOAuth2-Introduction">Introduction</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-Mavendependencies">Maven dependencies</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</a></li><ul><li><a
shape="rect" href="#JAX-RSOAuth2-AuthorizationService">Authorization Service</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-AccessTokenService">AccessTokenService</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-WritingOAuthDataProvider">Writing OAuthDataProvider</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-OAuthServerJAXRSendpoints">OAuth Server JAX-RS endpoints</a></li></ul><li><a
shape="rect" href="#JAX-RSOAuth2-ProtectingresourceswithOAuthfilters">Protecting resources
with OAuth filters</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Howtogettheuserloginname">How
to get the user login name</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Clientsidesupport">Client-side
support</a></li><li><a shape="r
 ect" href="#JAX-RSOAuth2-OAuth2withouttheExplicitAuthorization">OAuth2 without the Explicit
Authorization</a></li><li><a shape="rect" href="#JAX-RSOAuth2-OAuthWithoutaBrowser">OAuth
Without a Browser</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Designconsiderations">Design
considerations</a></li><ul><li><a shape="rect" href="#JAX-RSOAuth2-ControllingtheAccesstoResourceServer">Controlling
the Access to Resource Server</a></li><ul><li><a shape="rect" href="#JAX-RSOAuth2-Sharingthesameaccesspathbetweenendusersandconsumers">Sharing
the same access path between end users and consumers</a></li><li><a shape="rect"
href="#JAX-RSOAuth2-Providingdifferentaccesspointstoendusersandconsumers">Providing different
access points to end users and consumers</a></li></ul><li><a shape="rect"
href="#JAX-RSOAuth2-SingleSignOn">Single Sign On</a></li></ul><li><a
shape="rect" href="#JAX-RSOAuth2-WhatIsNext">What Is Next</a></li></ul></div>
 
 <h1><a shape="rect" name="JAX-RSOAuth2-Introduction"></a>Introduction</h1>
 
-<p>CXF 2.6.0 provides an initial implementation of <a shape="rect" class="external-link"
href="http://tools.ietf.org/html/draft-ietf-oauth-v2" rel="nofollow">OAuth 2.0</a>.
See also the <span class="error">[JAXRS OAuth]</span> page for the information
about OAuth 1.0.</p>
+<p>CXF 2.6.0 provides an initial implementation of <a shape="rect" class="external-link"
href="http://tools.ietf.org/html/draft-ietf-oauth-v2" rel="nofollow">OAuth 2.0</a>.
See also the <a shape="rect" href="jax-rs-oauth.html" title="JAX-RS OAuth">JAX-RS OAuth</a>
page for the information about OAuth 1.0.</p>
 
 <p>Authorization Code, Implicit and Client Credentials grants are currently supported
with the new grant handlers to be added later.<br clear="none">
 Custom grant handlers can be registered.</p>
@@ -439,50 +439,40 @@ Most likely, you'd want to deploy Access
 
 <h1><a shape="rect" name="JAX-RSOAuth2-ProtectingresourceswithOAuthfilters"></a>Protecting
resources with OAuth filters</h1>
 
-<p><a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/filters/OAuthRequestFilter.java">OAuthRequestFilter</a>
request handler can be used to protect the resource server when processing the requests from
the third-party consumers. Add it as a jaxrs:provider to the endpoint which deals with the
consumers requesting the resources.</p>
+<p><a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/filters/OAuthRequestFilter.java">OAuthRequestFilter</a>
request handler can be used to protect the resource server when processing the requests from
the third-party clients. Add it as a jaxrs:provider to the endpoint which deals with the consumers
requesting the resources.</p>
 
 <p>When checking a request like this:</p>
 
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <pre class="code-xml">
-Address: http://localhost:8080/services/user/calendar
+Address: http://localhost:8080/services/thirdPartyAccess/calendar
 Http-Method: GET
-Headers: {
-Accept=[application/XML], 
-Authorization=[OAuth oauth_signature_method=<span class="code-quote">"HMAC-SHA1"</span>,

-                     oauth_consumer_key=<span class="code-quote">"123456789"</span>,

-                     oauth_token=<span class="code-quote">"abc15aca-2073-4bde-b1be-1a02dc7ccafe"</span>,

-                     oauth_version=<span class="code-quote">"1.0"</span>, 
-                     oauth_signature=<span class="code-quote">"dU%2BhXPNFfFpX2sC74IOxzTjdVrY%3D"</span>]
+Headers: 
+{
+  Authorization=[Bearer 5b5c8e677413277c4bb8b740d522b378], 
+  Accept=[application/xml]
 }
 </pre>
 </div></div> 
 
 <p>the filter will do the following:</p>
 
-<p>1. It will validate the signature and will get Client and AccessToken from OAuthDataProvider.</p>
+<p>1. Retrieve a ServerAccessToken by delegating to a matching registered <a shape="rect"
class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/AccessTokenValidator.java">AccessTokenValidator</a>.
AccessTokenValidator is expected to check the validity of the incoming token parameters and
possibly delegate to OAuthDataProvider to find the token representation - this is what the
filter will default to if no matching AccessTokenValidator is found and the Authorization
scheme is 'Bearer'.</p>
 
-<p>2. It will check if <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/AccessToken.java">AccessToken</a>
have a "uris" property set and if yes then it will validate the current request URI against
it.</p>
+<p>2. Check the token has not expired</p>
 
-<p>3. If AccessToken has a list of <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/OAuthPermission.java">OAuthPermissions</a>.
For every permission it will:</p>
+<p>3. AccessToken may have a list of <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security2/oauth/data/OAuthPermission.java">OAuthPermissions</a>.
For every permission it will:</p>
 <ul class="alternate" type="square"><li>If it has a uri property set then the
current request URI will be checked against it</li><li>If it has an httpVerb property
set then the current HTTP verb will be checked against it</li></ul>
 
 
-<p>4. Finally, it will create a CXF <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/SecurityContext.java">SecurityContext</a>
using this list of <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/OAuthPermission.java">OAuthPermissions</a>
and the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/Client.java">Client</a>
loginName property.</p>
-
-<p>This loginName property is something that can be optionally associated with the
new Client during the registration - if it is not set then the filter will use a Client "applicationName"
property instead. The application code checking the user Principal will see the chosen value.
Additionally every OAuthPermission may have a list of application-specific roles such as "consumer",
etc, which will be added to SecurityContext and will be checked during SecurityContext.isUserInRole(roleName)
calls. </p>
-
-<p>If a "useUserSubject" property is set on the filter then a UserSubject associated
with the access token will be used to populate the SecurityContext.</p>
+<p>4. Finally, it will create a CXF <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/SecurityContext.java">SecurityContext</a>
using this list of <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/data/OAuthPermission.java">OAuthPermissions</a>,
the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/common/UserSubject.java">UserSubject</a>
representing the client or the end user who authorized the grant used to obtain this token.</p>
 
-<p>This SecurityContext will not necessarily be important for some of OAuth applications.
Most of the security checks will be done by OAuth filters and security filters protecting
the main application path the end users themselves use. Only if you would like to share the
same JAX-RS resource code and access URIs between end users and consumers then it can become
handy. More on it below. </p>
-
-<p>Note that <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/filters/OAuthServletFilter.java">OAuthServletFilter</a>
can be deployed instead. It will need the OAuthDataProvider full class name referenced as
an "oauth.data.provider-class" servlet context parameter.</p>
+<p>This SecurityContext will not necessarily be important for some of OAuth2 applications.
Most of the security checks will be done by OAuth2 filters and security filters protecting
the main application path the end users themselves use. Only if you would like to share the
same JAX-RS resource code and access URIs between end users and consumers then it can become
handy. More on it below. </p>
 
 <h1><a shape="rect" name="JAX-RSOAuth2-Howtogettheuserloginname"></a>How
to get the user login name</h1>
 
-<p>When one writes a custom server application which needs to participate in 3-leg
OAuth flows, the major question which needs to be addressed is<br clear="none">
-how one can access a user login name that was used during the end-user authorizing the third-party
client. This username will help to uniquely identify the resources that the 3rd party client
is now attempting to access.<br clear="none">
-The following code shows one way of how this can be done starting from CXF 2.5.1:</p>
+<p>When one writes a custom server application which needs to participate in OAuth2
flows, the major question which needs to be addressed is<br clear="none">
+how one can access a user login name that was used during the end-user authorizing the third-party
client. This username will help to uniquely identify the resources that the 3rd party client
is now attempting to access. The following code shows one way of how this can be done:</p>
 
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <pre class="code-java"> 
@@ -512,16 +502,11 @@ The following code shows one way of how 
 
 <p>The above shows a fragment of the JAX-RS service managing the access to user resources
from authorized 3rd-party clients (see the Design Considerations section for more information).</p>
 
-<p>The injected MessageContext provides an access to <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/OAuthContext.java">OAuthContext</a>
which has been set by OAuth filters described in the previous section. OAuthContext will act
as a container of the information which can be useful to the custom application code which
do not need to deal with the OAuth internals which will likely change between OAuth 1.0 and
OAuth 2.0. At the moment OAuthContext provides an access to <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/UserSubject.java">UserSubject</a>
which is created by CXF AuthorizationService at the moment of the end user authorizing the
third-party client and captures the end user's login name (and roles which will be available
if
  CXF JAASLoginInterceptor is used to authenticate end users) and associates it with the current
<a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/RequestToken.java">RequestToken</a>.
It will be a responsibility of custom OAuthDataProviders to make sure this UserSubject bean
is copied across to a corresponding <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/AccessToken.java">AccessToken</a>.
OAuthContext also references the list of the permissions which have been validated againt
the current client request.</p>
-
-<p>Additionally you may get OAuth filters to set up a SecurityContext which will use
the information available in <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/UserSubject.java">UserSubject</a>,
in other words, get the 3rd-party client impersonating the end user (which authorized this
client in the first place) for the duration of the current request. Set a jaxrs contextual
"org.apache.cxf.rs.security.oauth.use_user_subject" property to 'true'<br clear="none">
-for this to happen.</p>
+<p>The injected MessageContext provides an access to <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/common/OAuthContext.java">OAuthContext</a>
which has been set by OAuth2 filters described in the previous section. OAuthContext will
act as a container of the information which can be useful to the custom application code which
do not need to deal with the OAuth2 internals.</p>
 
 <h1><a shape="rect" name="JAX-RSOAuth2-Clientsidesupport"></a>Client-side
support</h1>
 
-<p>When developing a third party application which needs to participate in OAuth flows
one has to write the code that will redirect users to OAuth AuthorizationRequestService, interact
with RequestTokenService and AccessTokenService in order to get request and access tokens
as well as correctly build Authorization OAuth headers when accessing the end users' resources.
JAX-RS makes it straightforward to support the redirection, while <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/client/OAuthClientUtils.java">OAuthClientUtils</a>
class makes it possible to encapsulate most of the complexity away from the client application
code.   </p>
-
-<p>OAuthClientUtils has utility methods for getting request and access tokens, the
consumer is expected to provide a properly initialized WebClient pointing to either RequestTokenService
and AccessTokenService, Consumer bean containing the registration key and secret, a callback
URI for requesting a request token and the request Token and the verifier for requesting the
access token which is all quite straightforward. It also helps to create a proper URI for
redirecting to AuthorizationRequestService. A correct Authorization header will also need
to be used when accessing the user resources at the resource server and OAuthClientUtils will
help with creating this header as well.</p>
+<p>When developing a third party application which needs to participate in OAuth2 flows
one has to write the code that will redirect users to OAuth2 AuthorizationCodeGrantService,
interact with AccessTokenService in order to exchange code grants for access tokens as well
as correctly build Authorization OAuth2 headers when accessing the end users' resources. JAX-RS
makes it straightforward to support the redirection, while <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/OAuthClientUtils.java">OAuthClientUtils</a>
class makes it possible to encapsulate most of the complexity away from the client application
code.   </p>
 
 <p>For example, the following custom code can be used by the third-party application:</p>
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
@@ -529,87 +514,42 @@ for this to happen.</p>
 <span class="code-keyword">public</span> class OAuthClientManager {
 	
 	<span class="code-keyword">private</span> WebClient accessTokenService;
-        <span class="code-keyword">private</span> WebClient requestTokenService;
         <span class="code-keyword">private</span> <span class="code-object">String</span>
authorizationServiceURI;
-    
-        <span class="code-comment">// inject properties...
-</span>	
-	<span class="code-keyword">public</span> URI getAuthorizationServiceURI(<span
class="code-object">String</span> token) {
-	    <span class="code-keyword">return</span> OAuthClientUtils.getAuthorizationURI(authorizationServiceURI,
token);
-	}
-	
-	<span class="code-keyword">public</span> Token getRequestToken(URI callback)
{
-	    <span class="code-keyword">try</span> {
-	        <span class="code-keyword">return</span> OAuthClientUtils.getRequestToken(requestTokenService,
consumer, callback, <span class="code-keyword">null</span>);
-	    } <span class="code-keyword">catch</span> (OAuthServiceException ex) {
-               <span class="code-keyword">return</span> <span class="code-keyword">null</span>;
-            }    
+        <span class="code-keyword">private</span> Consumer consumer;
+
+        <span class="code-comment">// inject properties, register the client application...
+</span>
+	<span class="code-keyword">public</span> URI getAuthorizationServiceURI(ReservationRequest
request,
+			                              URI redirectUri,
+			                              /* state */<span class="code-object">String</span>
reservationRequestKey) {
+	    <span class="code-object">String</span> scope = OAuthConstants.UPDATE_CALENDAR_SCOPE
+ request.getHour();
+	    <span class="code-keyword">return</span> OAuthClientUtils.getAuthorizationURI(authorizationServiceURI,

+	    		                                consumer.getKey(),
+	    		                                redirectUri.toString(),
+	    		                                reservationRequestKey,
+	    		                                scope);
 	}
-	
-	<span class="code-keyword">public</span> Token getAccessToken(Token requestToken,
<span class="code-object">String</span> verifier) {
+	<span class="code-keyword">public</span> ClientAccessToken getAccessToken(AuthorizationCodeGrant
codeGrant) {
 	    <span class="code-keyword">try</span> {
-	        <span class="code-keyword">return</span> OAuthClientUtils.getAccessToken(accessTokenService,
consumer, requestToken, verifier);
+	        <span class="code-keyword">return</span> OAuthClientUtils.getAccessToken(accessTokenService,
consumer, codeGrant);
 	    } <span class="code-keyword">catch</span> (OAuthServiceException ex) {
 	        <span class="code-keyword">return</span> <span class="code-keyword">null</span>;
 	    }
 	}
 	
-	<span class="code-keyword">public</span> <span class="code-object">String</span>
createAuthorizationHeader(Token token, <span class="code-object">String</span>
method, <span class="code-object">String</span> requestURI) {
-            <span class="code-keyword">return</span> OAuthClientUtils.createAuthorizationHeader(consumer,
token, method, requestURI);
+	<span class="code-keyword">public</span> <span class="code-object">String</span>
createAuthorizationHeader(ClientAccessToken token) {
+		<span class="code-keyword">return</span> OAuthClientUtils.createAuthorizationHeader(consumer,
token);
 	}
 }
 </pre>
 </div></div>    
 
-<p>The reason such a simple wrapper can be introduced is to minimize the exposure to
OAuth of the main application code to the bare minimum, this is why<br clear="none">
+<p>The reason such a simple wrapper can be introduced is to minimize the exposure to
OAuth2 of the main application code to the bare minimum, this is why<br clear="none">
 in this example OAuthServiceExceptions are caught, presumably logged and null values are
returned which will indicate to the main code that the request failed. Obviously, OAuthClientUtils
can be used directly as well.</p>
 
-<h1><a shape="rect" name="JAX-RSOAuth2-2legOAuthFlow"></a>2-leg OAuth Flow</h1>
-
-<p>Please see this blog <a shape="rect" class="external-link" href="http://blog.nerdbank.net/2011/06/what-is-2-legged-oauth.html"
rel="nofollow">entry</a> for a good overview of the OAuth 2-leg flow.<br clear="none">
-Here are the variations of the 2-leg flow that CXF supports:</p>
-
-<h2><a shape="rect" name="JAX-RSOAuth2-ClientrequestsPreAuthorizedRequestToken"></a>Client
requests PreAuthorized RequestToken</h2>
-
-<p>In this variation the client accesses the request token as usual but skips the explicit
authorization step.<br clear="none">
-Instead, after the request token has been obtained, it requests the access token without
providing an "oauth_verifier" parameter. <br clear="none">
-For this to work RequestToken needs to be pre-authorized and have its UserSubject property
set. </p>
-
-<p>This is the only distinction from the typical 3-OAuth flow. OAuth filters will validate
the request as usual.</p>
-
-<h2><a shape="rect" name="JAX-RSOAuth2-SignaturewithConsumerKeyandSecret"></a>Signature
with Consumer Key and Secret  </h2>
-
-<p>In this mode the consumer key and secret pairs are used to create the "oauth_signature",
Authorization header will look pretty much the same as it does during RequestToken requests.</p>
-
-<p>In this mode the Client is expected to reference a pre-authorized AccessToken. OAuth
filters validate this token as usual.</p>
-
-<h2><a shape="rect" name="JAX-RSOAuth2-OnlyConsumerKeyandSecretinAuthorizationheader"></a>Only
Consumer Key and Secret in Authorization header</h2>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-xml"> 
-Address: http://localhost:8080/services/user/calendar
-Http-Method: GET
-Headers: {
-Accept=[application/XML], 
-Authorization=[OAuth oauth_consumer_key=<span class="code-quote">"123456789"</span>,oauth_consumer_secret=<span
class="code-quote">"987654321"</span>] 
-}
-</pre>
-</div></div> 
-
-<p>Alternatively, the consumer key and secret can be joined by a ":" character and
encoded with the Base64 encoding:</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-xml"> 
-Address: http://localhost:8080/services/user/calendar
-Http-Method: GET
-Headers: {
-Accept=[application/XML], 
-Authorization=[Basic base64EncodedValue] 
-}
-</pre>
-</div></div> 
+<h1><a shape="rect" name="JAX-RSOAuth2-OAuth2withouttheExplicitAuthorization"></a>OAuth2
without the Explicit Authorization</h1>
 
-<p>In this mode the Client is expected to reference a pre-authorized AccessToken. OAuth
filters validate this token as usual. </p>
+<p>Client Credentials is one of OAuth2 grants that does not require the explicit authorization
and is currently supported by CXF.  </p>
 
 <h1><a shape="rect" name="JAX-RSOAuth2-OAuthWithoutaBrowser"></a>OAuth
Without a Browser</h1>
 
@@ -630,7 +570,7 @@ However, supporting other types of end u
 
 <p>In the former case the way the authentication is managed is completely up to the
resource server application: basic authentication, two-way TLS, OpenId (more on it below),
you name it.</p>
 
-<p>In the latter case an OAuth filter must enforce that the 3rd party consumer has
been registered using the provided consumer key and that it has a valid access token (authorization
key in OAuth 2.0) which represents the end user's approval.  It's kind of the authentication
and the authorization check at the same time.</p>
+<p>In the latter case an OAuth filter must enforce that the 3rd party consumer has
been registered using the provided consumer key and that it has a valid access token which
represents the end user's approval.  It's kind of the authentication and the authorization
check at the same time.</p>
 
 <p>Letting both parties access the resource server via the same URI(s) complicates
the life for the security filters but all the parties are only aware of the single resource
server URI which all of them will use.</p>
 
@@ -641,17 +581,17 @@ However, supporting other types of end u
 <h3><a shape="rect" name="JAX-RSOAuth2-Sharingthesameaccesspathbetweenendusersandconsumers"></a>Sharing
the same access path between end users and consumers</h3>
 
 <p>The first problem which needs to be addressed is how to distinguish end users from
third-party consumers and get both parties authenticated as required.<br clear="none">
-Perhaps the simplest option is to extend a CXF OAuth filter (JAX-RS or servlet one), check
Authorization header, if it is OAuth then delegate to the superclass, alternatively - proceed
with authenticating the end users:</p>
+Perhaps the simplest option is to extend a CXF OAuth2 filter (JAX-RS or servlet one), check
Authorization header, if it is OAuth2 then delegate to the superclass, alternatively - proceed
with authenticating the end users:</p>
 
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
 <pre class="code-java">
-<span class="code-keyword">public</span> class SecurityFilter <span class="code-keyword">extends</span>
org.apache.cxf.rs.security.oauth.filters.OAuthRequestFilter {
+<span class="code-keyword">public</span> class SecurityFilter <span class="code-keyword">extends</span>
org.apache.cxf.rs.security.oauth2.filters.OAuthRequestFilter {
    @Context
    <span class="code-keyword">private</span> HttpHeaders headers;
 
    <span class="code-keyword">public</span> Response handleRequest(ClassResourceInfo
cri, Message message) {
        <span class="code-object">String</span> header = headers.getRequestHeaders().getFirst(<span
class="code-quote">"Authorization"</span>);
-       <span class="code-keyword">if</span> (header.startsWith(<span class="code-quote">"OAuth
"</span>)) {
+       <span class="code-keyword">if</span> (header.startsWith(<span class="code-quote">"Bearer
"</span>)) {
            <span class="code-keyword">return</span> <span class="code-keyword">super</span>.handleRequest(cri,
message);
        } <span class="code-keyword">else</span> {
            <span class="code-comment">// authenticate the end user
@@ -695,7 +635,7 @@ For example, consider the following JAX-
 1. update the calendar available at the same path <br clear="none">
 2. read the private Calendars available at "/calendar/{id}/private"</p>
 
-<p>As noted above, Client, AccessToken (in its Token superclass) and <a shape="rect"
class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth/src/main/java/org/apache/cxf/rs/security/oauth/data/OAuthPermission.java">OAuthPermission</a>
all have an optional URIs property. Thus one way to solve the problem with the private calendar
is to add, say, a uri "/calendar/{id}" or "/calendar/1" (etc) property to OAuthPermission
(representing a scope like "readCalendar") and the OAuth filter will make sure no subresources
beyond "/calendar/{id}" can be accessed. Note, adding a "*" at the end of a given URI property,
for example, "/a*" will let the consumer to access "/a", "/a/b", etc.</p>
+<p>As noted above, <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/common/OAuthPermission.java">OAuthPermission</a>
has an optional URIs property. Thus one way to solve the problem with the private calendar
is to add, say, a uri "/calendar/{id}" or "/calendar/1" (etc) property to OAuthPermission
(representing a scope like "readCalendar") and the OAuth filter will make sure no subresources
beyond "/calendar/{id}" can be accessed. Note, adding a "*" at the end of a given URI property,
for example, "/a*" will let the consumer to access "/a", "/a/b", etc.</p>
 
 <p>Solving the problem with preventing the update can be easily solved by adding an
httpVerb property to a given OAuthPermission.</p>
 
@@ -713,8 +653,8 @@ For example, consider the following JAX-
 
 <h1><a shape="rect" name="JAX-RSOAuth2-WhatIsNext"></a>What Is Next</h1>
 
-<p>Fine tuning the current OAuth 1.0 will be continued and the feedback from the implementers
will be welcomed.<br clear="none">
-OAuth 2.0 is going to become a very major specification in the whole RESTful space and CXF
will implement the selected OAuth 2.0 profiles. Among other things, OAuth 2.0 will also rely
on SAML in one of the extensions and we'll look into it too. Writing a complete OAuth application
will most likely require some SSO solution so some support from CXF can be expected.</p>
+<p>Fine tuning the current OAuth 2.0 implementation will be continued and the feedback
from the implementers will be welcomed.<br clear="none">
+OAuth 2.0 grants based on SAML2 or JWT assertions, OAuth 2.0 extensions - are all of interest
to CXF.</p>
 </div>
            </div>
            <!-- Content -->



Mime
View raw message