cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r908714 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth.html
Date Tue, 13 May 2014 16:46:52 GMT
Author: buildbot
Date: Tue May 13 16:46:51 2014
New Revision: 908714

Log:
Production update by buildbot for cxf

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

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

Modified: websites/production/cxf/content/docs/jax-rs-oauth.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-oauth.html (original)
+++ websites/production/cxf/content/docs/jax-rs-oauth.html Tue May 13 16:46:51 2014
@@ -119,11 +119,11 @@ Apache CXF -- JAX-RS OAuth
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><span style="font-size:2em;font-weight:bold"> JAX-RS:
OAuth </span><p>&#160;</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1399992387153 {padding: 0px;}
-div.rbtoc1399992387153 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1399992387153 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1399999585261 {padding: 0px;}
+div.rbtoc1399999585261 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1399999585261 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1399992387153">
+/*]]>*/</style></p><div class="toc-macro rbtoc1399999585261">
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth-Introduction">Introduction</a></li><li><a
shape="rect" href="#JAX-RSOAuth-Mavendependencies">Maven dependencies</a></li><li><a
shape="rect" href="#JAX-RSOAuth-DevelopingOAuth1.0Servers">Developing OAuth 1.0 Servers</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth-RequestTokenService">RequestTokenService</a></li><li><a
shape="rect" href="#JAX-RSOAuth-AuthorizationRequestService">AuthorizationRequestService</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth-OOBcallbacks">OOB
callbacks</a></li></ul>
@@ -135,7 +135,7 @@ div.rbtoc1399992387153 li {margin-left: 
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth-Sharingthesameaccesspathbetweenendusersandconsumers">Sharing
the same access path between end users and consumers</a></li><li><a shape="rect"
href="#JAX-RSOAuth-Providingdifferentaccesspointstoendusersandconsumers">Providing different
access points to end users and consumers</a></li></ul>
 </li><li><a shape="rect" href="#JAX-RSOAuth-SingleSignOn">Single Sign On</a></li></ul>
 </li><li><a shape="rect" href="#JAX-RSOAuth-WhatIsNext">What Is Next</a></li></ul>
-</div><h1 id="JAX-RSOAuth-Introduction">Introduction</h1><p>CXF 2.5.0
implements <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc5849"
rel="nofollow">OAuth 1.0</a>. Please also see the <a shape="rect" href="jax-rs-oauth2.html">JAX-RS
OAuth2</a> about the OAuth2 support in CXF.</p><p>While <a shape="rect"
class="external-link" href="http://oauth.net/2/" rel="nofollow">OAuth 2.0</a> (which
is very close to becoming the final recommendation) is the next major version of OAuth, OAuth
1.0 has been implemented by many providers and the CXF OAuth 1.0 module should make it easy
for developers to start writing OAuth 1.0 applications.</p><p>OAuth 1.0 offers
a complex yet elegant solution toward helping the end users (resource owners) authorize third-party
providers to access their resources.</p><p>The classical OAuth flow is also called
a 3-leg OAuth flow as it involves 3 parties: the end user (resource owner), the third party
service (client, consumer) and the resou
 rce server which is protected by OAuth filters. Typically a consumer offers a service feature
that an end user requests and which requires the former to access one or more resources of
this end user which are located at the resource server. For example, the consumer may need
to access the end user's photos in order to print them and post to the user or read and possibly
update a user's calendar in order to make a booking.</p><p>In order to make it
happen, the third-party service application/consumer needs to register itself with the OAuth
server. This happens out-of-band and after the registration the consumer gets back a consumer
key and secret pair. For example, see this page for one <a shape="rect" class="external-link"
href="http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html" rel="nofollow">approach</a>.
The registrations of third-party application does not have to be very involved for simpler
applications.</p><p>From then on, the typical flow works like t
 his:<br clear="none"> 1. End User requests the third-party service using a browser.</p><p>2.
Third-party service requests a temporarily request token from OAuth RequestToken Service;
this token will represent a consumer's intention to access whatever end user resources it
needs to complete the current user's request.</p><p>3. After getting a request
token back, the consumer redirects the end user to OAuth Authorization Service and adds the
request token to the target URI.</p><p>4. Authorization Service will get all the
details about the current consumer using a request token, build an HTML form and return it
to the end user. The form will ask the user if a given third-party application can be allowed
to access some resources on behalf of this user.</p><p>5. If the user approves
it then Authorization Service will redirect the user back to the callback uri provided by
the consumer when requesting a request token, including a generated verifier (authorization
key) which 'links' the use
 r's approval with the request token.</p><p>6. Now the third-party service requests
an access token from OAuth AccessToken Service by providing a request token and its verifier.</p><p>7.
After getting an access token token, the service finally proceeds with accessing the current
user's resources and completes the user's request.</p><p>As noted above, the consumer
needs to register first with the OAuth server. It's a good practice to provide an application
name and so called connect URI which is typically a public URI of this application; the former
will be used by OAuth Authorization Service at step 4 above and the latter will be used at
step 2 to validate the provided callback URI to make sure it starts from the URI which was
actually provided during the registration.</p><p>As you can see the flow can be
complex yet it is functional. A number of issues may need to be taken care along the way such
as managing expired tokens, making sure that the OAuth security layer is functioning pr
 operly and is not interfering with the end user itself trying to access its own resources,
etc.</p><p>Please check the <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc5849"
rel="nofollow">specification</a> and the <a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/OAuth" rel="nofollow">Wikipedia article</a> as
well as other resources available on the WEB for more information you may need to know about
OAuth.</p><p>CXF JAX-RS gives the best effort to making this process as simple
as possible and requiring only a minimum effort on behalf of OAuth server developers. It also
offers the utility code for greatly simplifying the way the third-party application can interact
with the OAuth service endpoints.</p><h1 id="JAX-RSOAuth-Mavendependencies">Maven
dependencies</h1><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</div><h1 id="JAX-RSOAuth-Introduction">Introduction</h1><p>CXF 2.5.0
implements <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc5849"
rel="nofollow">OAuth 1.0</a>. Please also see the <a shape="rect" href="jax-rs-oauth2.html">JAX-RS
OAuth2</a> about the OAuth2 support in CXF.</p><p>While <a shape="rect"
class="external-link" href="http://oauth.net/2/" rel="nofollow">OAuth 2.0</a> (which
is very close to becoming the final recommendation) is the next major version of OAuth, OAuth
1.0 has been implemented by many providers and the CXF OAuth 1.0 module should make it easy
for developers to start writing OAuth 1.0 applications.</p><p>OAuth 1.0 offers
a complex yet elegant solution toward helping the end users (resource owners) authorize third-party
providers to access their resources.</p><p>The classical OAuth flow is also called
a 3-leg OAuth flow as it involves 3 parties: the end user (resource owner), the third party
service (client, consumer) and the resou
 rce server which is protected by OAuth filters. Typically a consumer offers a service feature
that an end user requests and which requires the former to access one or more resources of
this end user which are located at the resource server. For example, the consumer may need
to access the end user's photos in order to print them and post to the user or read and possibly
update a user's calendar in order to make a booking.</p><p>In order to make it
happen, the third-party service application/consumer needs to register itself with the OAuth
server. This happens out-of-band and after the registration the consumer gets back a consumer
key and secret pair. For example, see this page for one <a shape="rect" class="external-link"
href="http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html" rel="nofollow">approach</a>.
The registrations of third-party application does not have to be very involved for simpler
applications.</p><p>From then on, the typical flow works like t
 his:<br clear="none"> 1. End User requests the third-party service using a browser.</p><p>2.
Third-party service requests a temporarily request token from OAuth RequestToken Service;
this token will represent a consumer's intention to access whatever end user resources it
needs to complete the current user's request.</p><p>3. After getting a request
token back, the consumer redirects the end user to OAuth Authorization Service and adds the
request token to the target URI.</p><p>4. Authorization Service will get all the
details about the current consumer using a request token, build an HTML form and return it
to the end user. The form will ask the user if a given third-party application can be allowed
to access some resources on behalf of this user.</p><p>5. If the user approves
it then Authorization Service will redirect the user back to the callback uri provided by
the consumer when requesting a request token, including a generated verifier (authorization
key) which 'links' the use
 r's approval with the request token.</p><p>6. Now the third-party service requests
an access token from OAuth AccessToken Service by providing a request token and its verifier.</p><p>7.
After getting an access token, the service finally proceeds with accessing the current user's
resources and completes the user's request.</p><p>As noted above, the consumer
needs to register first with the OAuth server. It's a good practice to provide an application
name and so called connect URI which is typically a public URI of this application; the former
will be used by OAuth Authorization Service at step 4 above and the latter will be used at
step 2 to validate the provided callback URI to make sure it starts from the URI which was
actually provided during the registration.</p><p>As you can see the flow can be
complex yet it is functional. A number of issues may need to be taken care along the way such
as managing expired tokens, making sure that the OAuth security layer is functioning properly
  and is not interfering with the end user itself trying to access its own resources, etc.</p><p>Please
check the <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc5849"
rel="nofollow">specification</a> and the <a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/OAuth" rel="nofollow">Wikipedia article</a> as
well as other resources available on the WEB for more information you may need to know about
OAuth.</p><p>CXF JAX-RS gives the best effort to making this process as simple
as possible and requiring only a minimum effort on behalf of OAuth server developers. It also
offers the utility code for greatly simplifying the way the third-party application can interact
with the OAuth service endpoints.</p><h1 id="JAX-RSOAuth-Mavendependencies">Maven
dependencies</h1><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;dependency&gt;
   &lt;groupId&gt;org.apache.cxf&lt;/groupId&gt;
   &lt;artifactId&gt;cxf-rt-rs-security-oauth&lt;/artifactId&gt;
@@ -188,15 +188,15 @@ Referer=[http://localhost:8080/services/
 ]]></script>
 </div></div><p>First, AuthorizationRequestService will retrieve <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>
(which extends the base <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/Token.java">Token</a>
class) from OAuthDataProvider using the value provided by the "oauth_token" query parameter.</p><p>Next
it uses this token (which also links to Client) to populate an instance 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/OAuthAuthorizationData.java">OAuthAuthorizationData</a>
bean and returns it. OAuthAuthorizationData contains application name and URI properties,
optional l
 ist 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/Permission.java">Permission</a>s
and URIs.</p><p>Two other important OAuthAuthorizationData properties are "oauthToken"
and "authenticityToken", both are important for processing the decision request coming from
the authorization form. The former is a request token key which will be used by AuthorizationRequestService
to retrieve the RequestToken again and the latter for validating that the current session
has not been hijacked - AuthorizationRequestService generates a random key, stores it in a
Servlet HTTPSession instance and expects the returned authenticityToken value to match it
- this is a recommended approach and it also implies that the authenticityToken value is hidden
from a user, for example, it's kept in a 'hidden' form field.</p><p>The helper
"replyTo" property is an absolute URI identifying th
 e AuthorizationRequestService handler processing the user decision and can be used by view
handlers when building the forms or by other OAuthAuthorizationData handlers.</p><p>So
the populated OAuthAuthorizationData is finally returned. Note that it's a JAXB XMLRootElement-annotated
bean and can be processed by registered JAXB or JSON providers given that AuthorizationRequestService
supports producing "application/xml" and "application/json" (See the OAuth Without Browser
section below for more). But in this case we have the end user working with a browser so an
HTML form is what is really expected back.</p><p>AuthorizationRequestService supports
producing "text/html" and simply relies on a registered <a shape="rect" href="http://cxf.apache.org/docs/jax-rs-redirection.html#JAX-RSRedirection-WithRequestDispatcherProvider">RequestDispatcherProvider</a>
to set the OAuthAuthorizationData bean as an HttpServletRequest attribute and redirect the
response to a view handler (can be JSP or so
 me other servlet) to actually build the form and return it to the user. Alternatively, registering
<a shape="rect" href="http://cxf.apache.org/docs/jax-rs-advanced-xml.html#JAX-RSAdvancedXML-XSLTsupport">XSLTJaxbProvider</a>
would also be a good option for creating HTML views.</p><p>Assuming RequestDispatcherProvider
is used, the following example log shows the initial response from AuthorizationRequestService:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[08-Nov-2011
13:32:40 org.apache.cxf.jaxrs.provider.RequestDispatcherProvider logRedirection
-INFO: Setting an instance of &quot;org.apache.cxf.rs.security.oauth.data.OAuthAuthorizationData&quot;
as HttpServletRequest attribute 
-&quot;data&quot; and redirecting the response to &quot;/forms/oauthAuthorize.jsp&quot;.
+INFO: Setting an instance of &quot;org.apache.cxf.rs.security.oauth.data.OAuthAuthorizationData&quot;

+as HttpServletRequest attribute &quot;data&quot; and redirecting the response to
&quot;/forms/oauthAuthorize.jsp&quot;.
 
 08-Nov-2011 13:32:40 org.apache.cxf.interceptor.LoggingOutInterceptor
 ---------------------------
 Response-Code: 200
 Content-Type: text/html
 ]]></script>
-</div></div><p>Note that a "/forms/oauthAuthorize.jsp" view handler will
create an HTML view - this is a custom JSP handler and whatever HTML view is required can
be created there, using the OAuthAuthorizationData bean for building the view. Most likely
you will want to present a form asking the user to allow or deny the consumer accessing some
of this user's resources. If OAuthAuthorizationData has a list of Permissions set then addig
the information about the permissions is needed, same for a list of URIs.</p><p>Next
the user makes a decision and selects a button allowing or denying the consumer accessing
the resources. AuthorizationRequestService does not need to know how a user has been asked
to make the decision, but it expects to receive a form-based submission containing the following
3 parameters, named "session_authenticity_token" and "oauth_token" with values matching those
of OAuthAuthorizationData's "authenticityToken" and "oauthToken" properties, and "oAuthDecision"
wit
 h either "allow" or "deny" values:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+</div></div><p>Note that a "/forms/oauthAuthorize.jsp" view handler will
create an HTML view - this is a custom JSP handler and whatever HTML view is required can
be created there, using the OAuthAuthorizationData bean for building the view. Most likely
you will want to present a form asking the user to allow or deny the consumer accessing some
of this user's resources. If OAuthAuthorizationData has a list of Permissions set then adding
the information about the permissions is needed, same for a list of URIs.</p><p>Next
the user makes a decision and selects a button allowing or denying the consumer accessing
the resources. AuthorizationRequestService does not need to know how a user has been asked
to make the decision, but it expects to receive a form-based submission containing the following
3 parameters, named "session_authenticity_token" and "oauth_token" with values matching those
of OAuthAuthorizationData's "authenticityToken" and "oauthToken" properties, and "oAuthDecision"
wi
 th either "allow" or "deny" values:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[Address:
http://localhost:8080/services/social/authorize/decision
 Http-Method: POST
 Content-Type: application/x-www-form-urlencoded
@@ -207,7 +207,8 @@ Referer=[http://localhost:8080/services/
 User-Agent=[Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0]}
 --------------------------------------
 09-Nov-2011 16:41:58 org.apache.cxf.jaxrs.utils.FormUtils logRequestParametersIfNeeded
-INFO: session_authenticity_token=e52b5033-9bf5-4b34-9d3a-39a7d5b7e686&amp;oauthDecision=allow&amp;oauth_token=6dfd5e52-236c-4939-8df8-a53212f7d2a2
+INFO: session_authenticity_token=e52b5033-9bf5-4b34-9d3a-39a7d5b7e686&amp;oauthDecision=allow
+&amp;oauth_token=6dfd5e52-236c-4939-8df8-a53212f7d2a2
 ]]></script>
 </div></div><p>AuthorizationRequestService will use a session_authenticity_token
to validate that the session is valid and will process the user decision next.<br clear="none">
If it is set to "allow" then it will ask OAuthDataProvider to generate an authorization key
(verifier) and return this verifier alongside with the request token key and the state if
any by redirecting the current user back to the callback URI provided during the request token
request:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[Response-Code:
303
@@ -373,7 +374,7 @@ public class ThirdPartyAccessService {
 }
 
 ]]></script>
-</div></div><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">UserSubje
 ct</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 t
 o 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><h1 id="JAX-RSOAuth-Client-sidesupport">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' re
 sources. 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>For
example, the following custom code can be used by the third-party application:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+</div></div><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">UserSubje
 ct</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 t
 o 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' for this to happen.</p><h1
id="JAX-RSOAuth-Client-sidesupport">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 m
 akes 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 ser
 ver and OAuthClientUtils will help with creating this header as well.</p><p>For
example, the following custom code can be used by the third-party application:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[public
class OAuthClientManager {
 	
 	private WebClient accessTokenService;
@@ -407,7 +408,7 @@ public class ThirdPartyAccessService {
 	}
 }
 ]]></script>
-</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"> 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 id="JAX-RSOAuth-2-legOAuthFlow">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 id="JAX-RSOAuth-ClientrequestsPreAuthorizedRequestToken">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 r
 equest 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
id="JAX-RSOAuth-SignaturewithConsumerKeyandSecret">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 id="JAX-RSOAuth-OnlyConsumerKeyandSecretinAuthorizationheader">Only
Consumer Key and Secret in Authorization header</h2><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+</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
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 id="JAX-RSOAuth-2-legOAuthFlow">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 id="JAX-RSOAuth-ClientrequestsPreAuthorizedRequestToken">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 id="JAX-RSOAuth-SignaturewithConsumerKeyandSecret">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
id="JAX-RSOAuth-OnlyConsumerKeyandSecretinAuthorizationheader">Only Consumer Key and Secret
in Authorization header</h2><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
 <script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[

 Address: http://localhost:8080/services/user/calendar
 Http-Method: GET



Mime
View raw message