cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r953902 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth2.html
Date Fri, 05 Jun 2015 11:47:02 GMT
Author: buildbot
Date: Fri Jun  5 11:47:01 2015
New Revision: 953902

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 Fri Jun  5 11:47:01 2015
@@ -118,11 +118,11 @@ Apache CXF -- JAX-RS OAuth2
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><h1 id="JAX-RSOAuth2-JAX-RS:OAuth2">JAX-RS: OAuth2</h1><p><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1433501218341 {padding: 0px;}
-div.rbtoc1433501218341 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1433501218341 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1433504819250 {padding: 0px;}
+div.rbtoc1433504819250 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1433504819250 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1433501218341">
+/*]]>*/</style></p><div class="toc-macro rbtoc1433504819250">
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-JAX-RS:OAuth2">JAX-RS:
OAuth2</a></li><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-ClientRegistration">Client Registration</a></li><li><a
shape="rect" href="#JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-AuthorizationService">Authorization
Service</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-HowtocreateAuthorizationView">How
to create Authorization View</a></li><li><a shape="rect" href="#JAX-RSOAuth2-EndUserNameinAuthorizationForm">EndUser
Name in Authorization Form</a></li><li><a shape="rect" href="#JAX-RSOAuth2-PublicClients(Devices)">Public
Clients (Devices)</a>
@@ -661,7 +661,7 @@ public Response reserve(@Context ClientT
         &lt;jaxrs:providers&gt;
            &lt;!-- other providers --&gt;
 
-           &lt;bean class=&quot;oauth2.thirdparty.ClientTokenContextProviderImpl&quot;/&gt;
+           &lt;bean class=&quot;oauth2.thirdparty.CustomClientTokenContextProvider&quot;/&gt;
            &lt;bean class=&quot;org.apache.cxf.rs.security.oauth2.client.ClientCodeRequestFilter&quot;&gt;
                &lt;property name=&quot;authorizationServiceUri&quot; value=&quot;http://localhost:8080/services/authorize&quot;/&gt;
                &lt;property name=&quot;accessTokenServiceClient&quot; ref=&quot;atServiceClient&quot;/&gt;
@@ -691,7 +691,45 @@ public Response reserve(@Context ClientT
 
 
 ]]></script>
-</div></div><p>&#160;ClientCodeRequestFilter redirects to 'authorizationServiceUri'
when a 'startUri' is matched.</p><p>In the above example the filter uses a custom
'clientCodeStateManager' (org.apache.cxf.rs.security.oauth2.client.ClientCodeStateManager
implementation) for keeping the original request state for it to be available later on to
the applicationc code - this is optional and is only needed if the redirection request depends
on the request parameters (example, Oauth2 scope values are dynamic such as updateCalendar-7
where '7' is the hour) . By default, CXF ships some state managers out of the box, at the
moment these are MemoryClientCodeStateManager and JoseClientCodeStateManager implementations,
the latter signs and/or encrypts the request state and saves it in the HTTP session.</p><h2
id="JAX-RSOAuth2-OAuth2clientauthenticatorsfornon-dynamicclients">OAuth2 client authenticators
for non-dynamic clients</h2><p>Not all clients that may need to access an OAuth2-protected
a
 pplication server can be modified. Furthermore, not all OAuth2 clients can participate in
advanced flows such as an authorization code flow and need to be initialized with access and
refresh tokens.</p><p>CXF HTTPConduit HttpAuthSupplier supporting access and refresh
tokens is shipped starting from CXF 3.0.5 .</p><p>org.apache.cxf.rs.security.oauth2.client.BearerAuthSupplier
supports creating HTTP Authorization header from bearer access tokens, refreshing them proactively
or in response to 401 failures and recreating HTTP Authorization from the refreshed token.</p><p>It
is not possible to refresh a token from a JAX-RS ClientRequestFilter because such a filter
does not handle HTTP responses so it can not detect 401 (returned by a server if the access
token has expired), while HTTPConduit HttpAuthSupplier gets a chance to react to 401 and retry.</p><p>Here
is a configuration example:</p><p>&#160;</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelCo
 ntent pdl">
+</div></div><p>&#160;ClientCodeRequestFilter redirects to 'authorizationServiceUri'
when a 'startUri' is matched.</p><p>In the above example the filter uses a custom
'clientCodeStateManager' (org.apache.cxf.rs.security.oauth2.client.ClientCodeStateManager
implementation) for keeping the original request state before redirecting for it to be available
later on to the application code - this is optional and is only needed if the redirection
request depends on the request parameters (example, Oauth2 scope values are dynamic such as
updateCalendar-7 where '7' is the hour) . By default, CXF ships some state managers out of
the box, at the moment these are MemoryClientCodeStateManager and JoseClientCodeStateManager
implementations, the latter signs and/or encrypts the request state and saves it in the HTTP
session.</p><p>After the user is redirected back the filter exchanges the code
for a new access token and sets this token and the original redirection state in ClientTokenContext.
Note 
 CllientTokenContext makes the original request state available to the application as MultivaluedMap.</p><p>CXF
also ships a default ClientTokenContext implementation, a simple org.apache.cxf.rs.security.oauth2.client.ClientTokenContextImpl
bean. Finally CXF ships org.apache.cxf.rs.security.oauth2.client.ClientTokenContextProvider
to ensure ClientTokenContext can be available as JAX-RS context. Note though that the above
configuration registers a custom ClientTokenContext provider ('oauth2.thirdparty.CustomClientTokenContextProvider')
instead - this is optional and is only needed if it is preferred for the application code
to access the state in a type safe way (example, via ReservationRequest type as shown above),
such a provider can be implemented like this:</p><p>&#160;</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[import
javax.ws.rs.core.MultivaluedMap;
+import org.apache.cxf.jaxrs.ext.ContextProvider;
+import org.apache.cxf.message.Message;
+import org.apache.cxf.rs.security.oauth2.client.ClientTokenContext;
+import org.apache.cxf.rs.security.oauth2.client.ClientTokenContextProvider;
+import org.apache.cxf.rs.security.oauth2.common.ClientAccessToken;
+
+public class CustomClientTokenContextProvider extends ClientTokenContextProvider {
+    @Override
+    public ClientTokenContext createContext(Message m) {
+        return new WrapClientTokenContext(super.createContext(m));
+    }
+    private static class WrapClientTokenContext implements ClientTokenContext {
+        private ClientTokenContext ctx;
+        public WrapClientTokenContext(ClientTokenContext ctx) { 
+            this.ctx = ctx;
+        }
+        @Override
+        public MultivaluedMap&lt;String, String&gt; getState() {
+            return ctx.getState();
+        }
+        @Override
+        public &lt;T&gt; T getState(Class&lt;T&gt; cls) {
+            if (ReservationRequest.class == cls) {
+                MultivaluedMap&lt;String, String&gt; state = getState();
+                return (T)new ReservationRequest(state.getFirst(&quot;name&quot;),
+                                              state.getFirst(&quot;phone&quot;),
+                                              Integer.parseInt(state.getFirst(&quot;hour&quot;)));
+            }
+            return ctx.getState(cls);
+        }
+        @Override
+        public ClientAccessToken getToken() {
+            return ctx.getToken();
+        }
+    }
+}]]></script>
+</div></div><p>&#160;</p><p>ClientCodeRequestFilter can
also be configured with org.apache.cxf.rs.security.oauth2.client.ClientTokenContextManager
('clientTokenContextManager' property) to support a case where the same user is returning
with the same request and the access token granted previously has not expired yet. At the
moment CXF ships only MemoryClientTokenContextManager with the JOSE-aware provider to follow.
If the manager is registered and the context (and the access token) for the current user is
found then the request goes ahead without the redirection. In this case the filter can pro-actively
refresh the token if it has already expired or close to being expired ('expiryThreshold' property,
example, if it is set to 5 secs and the filter sees that the token will expire in less than
5 sec then it will try to refresh).</p><p>ClientCodeRequestFilter can also be
configured with a 'scopes' property when static OAuth2 scopes are used for all the users (note
'scope' is one of re
 direct parameters typically sent to OAuth2 servers)</p><p>Note a similar filter
support is availble for client applications depending on OIDC RP authentication.</p><h2
id="JAX-RSOAuth2-OAuth2clientauthenticatorsfornon-dynamicclients">OAuth2 client authenticators
for non-dynamic clients</h2><p>Not all clients that may need to access an OAuth2-protected
application server can be modified. Furthermore, not all OAuth2 clients can participate in
advanced flows such as an authorization code flow and need to be initialized with access and
refresh tokens.</p><p>CXF HTTPConduit HttpAuthSupplier supporting access and refresh
tokens is shipped starting from CXF 3.0.5 .</p><p>org.apache.cxf.rs.security.oauth2.client.BearerAuthSupplier
supports creating HTTP Authorization header from bearer access tokens, refreshing them proactively
or in response to 401 failures and recreating HTTP Authorization from the refreshed token.</p><p>It
is not possible to refresh a token from a JAX-RS ClientRequestFil
 ter because such a filter does not handle HTTP responses so it can not detect 401 (returned
by a server if the access token has expired), while HTTPConduit HttpAuthSupplier gets a chance
to react to 401 and retry.</p><p>Here is a configuration example:</p><p>&#160;</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[&lt;beans&gt;
 &lt;bean id=&quot;consumer&quot; class=&quot;org.apache.cxf.rs.security.oauth2.client.Consumer&quot;&gt;
    &lt;property name=&quot;clientId&quot; value=&quot;1&quot;/&gt;



Mime
View raw message