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 -->
