svn commit: r955653 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth2.html

[bu...@apache.org]

Author: buildbot
Date: Mon Jun 22 09:47:32 2015
New Revision: 955653

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 Mon Jun 22 09:47:32 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.rbtoc1433504819250 {padding: 0px;}
-div.rbtoc1433504819250 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1433504819250 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1434966447437 {padding: 0px;}
+div.rbtoc1434966447437 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1434966447437 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1433504819250">
+/*]]>*/</style></p><div class="toc-macro rbtoc1434966447437">
 <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>
@@ -140,7 +140,7 @@ div.rbtoc1433504819250 li {margin-left:
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-DefaultProviders">Default Providers</a></li></ul>
 </li><li><a shape="rect" href="#JAX-RSOAuth2-OAuthServerJAX-RSendpoints">OAuth Server JAX-RS endpoints</a></li></ul>
 </li><li><a shape="rect" href="#JAX-RSOAuth2-ThirdPartyClientAuthentication">Third Party Client Authentication</a></li><li><a shape="rect" href="#JAX-RSOAuth2-UserSessionAuthenticity">User Session Authenticity</a>
-<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-MultipleFactorVerification">Multiple Factor Verification</a></li></ul>
+<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-Keepingthestateinthesession">Keeping the state in the session</a></li><li><a shape="rect" href="#JAX-RSOAuth2-MultipleFactorVerification">Multiple Factor Verification</a></li></ul>
 </li><li><a shape="rect" href="#JAX-RSOAuth2-CustomizingEndUserSubjectinitialization">Customizing End User Subject initialization</a></li><li><a shape="rect" href="#JAX-RSOAuth2-ProtectingresourceswithOAuthfilters">Protecting resources with OAuth filters</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-OAuth2tokensandSOAPendpoints">OAuth2 tokens and SOAP endpoints</a></li></ul>
 </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-Client-sidesupport">Client-side support</a>
@@ -417,7 +417,7 @@ ModelEncryptionSupport.decryptAccessToke
   &lt;/jaxrs:serviceBeans&gt;
 &lt;/jaxrs:server&gt;
 ]]></script>
-</div></div><p>AuthorizationCodeGrantService listens on a relative "/authorize" path so in this case its absolute address will be something like "http://localhost:8080/services/myapp/authorize". This address and that of AccessTokenService will be used by third-party clients.</p><h1 id="JAX-RSOAuth2-ThirdPartyClientAuthentication">Third Party Client Authentication</h1><p>When a client requests a token from Access Token Service, it needs to get authenticated. Providing its client_id and client secret as part of Basic Authorization scheme or posting them directly as form parameters are typical options, however other authentication schemes can easily be supported if required.</p><p>For example, using client certificates or assertions like SAML2 Bearer or JWT is all acceptable - the only additional requirement in this case is that a given security filter processing a specific authentication scheme maps the client credentials to an actual client_id - CXF Access Token Service will check a 
 "client_id" property on the current message context as the last resort. Note that org.apache.cxf.rs.security.oauth2.provider.ClientIdProvider can be registered with AccessTokenService to facilitate the mapping between an authenticated client and its id expected by the data provider if the container or filter based authentication can not set a "client_id" contextual property.</p><p>If a Basic authentication scheme is used and neither the container or filter has authenticated the client AccessTokenService will request a Client from the data provider and compare the Client's secret against the password found in the Basic scheme data. org.apache.cxf.rs.security.oauth2.provider.ClientSecretVerifier is available starting from CXF 3.0.3 to support Clients saving only password hashes. Its org.apache.cxf.rs.security.oauth2.provider.ClientSecretHashVerifier (calculates a SHA-256 password hash and compares it with the Client's secret) or custom implementations can be registered with AccessToke
 nService.</p><p>If a 2-way TLS is sued to authenticate a client and Client has a Base64 encoded representations of its X509Certificates available in its "applicationCertificates" property then AccessTokenService will do the additional comparison of these certificates against the ones available in the current TLS session.</p><p>&#160;</p><p>Please see <a shape="rect" href="jaxrs-oauth2-assertions.html">JAXRS OAuth2 Assertions</a> section for more information on how it may work.</p><p>&#160;</p><h1 id="JAX-RSOAuth2-UserSessionAuthenticity">User Session Authenticity</h1><p>Redirection-based Authorization Code and Implicit flows depend on end users signing in if needed during the initial redirection, challenged with the client authorization form and returning their decision. By default, CXF will enforce the user session authenticity by keeping the session state in a servlet container's HTTPSession. If the alternative storage is preferred then you can register a new <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> (available from CXF 2.6.4) with either AuthorizationCodeGrantService or ImplicitGrantService beans.</p><h3 id="JAX-RSOAuth2-MultipleFactorVerification">Multiple Factor Verification</h3><p>Note that <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> has been updated in CXF 3.0.2 to accept request parameters and a reference to the authenticated user. This allows for introducing a multiple factor session verification: when the provider created a session property it can for example sent a message to a user's mobile phone expect the authorization consent form 
 return the sent value.</p><p>The other minor enhancement is that RedirectionBasedGrantService will check the authorization content form for the name of the form property that contains a session authentication property, using a "session_authenticity_token_param_name" property name. This allows for the 'rotation' of hidden form properties containing the actual session authenticity values.</p><h1 id="JAX-RSOAuth2-CustomizingEndUserSubjectinitialization">Customizing End User Subject initialization</h1><p>By default, redirection based authorization services will the the current CXF SecurityContext to initialize a subject representing the authenticated resource owner/end user. If the customization if needed: custom CXF filter can be used to create UserSubject and set it on the message or org.apache.cxf.rs.security.oauth2.provider.SubjectCreator interface implementation can be registered with either AuthorizationCodeGrantService or ImplicitGrantService.</p><h1 id="JAX-RSOAuth2-Protectingre
 sourceswithOAuthfilters">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/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 clients requesting the resources.</p><p>When checking a request like this:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>AuthorizationCodeGrantService listens on a relative "/authorize" path so in this case its absolute address will be something like "http://localhost:8080/services/myapp/authorize". This address and that of AccessTokenService will be used by third-party clients.</p><h1 id="JAX-RSOAuth2-ThirdPartyClientAuthentication">Third Party Client Authentication</h1><p>When a client requests a token from Access Token Service, it needs to get authenticated. Providing its client_id and client secret as part of Basic Authorization scheme or posting them directly as form parameters are typical options, however other authentication schemes can easily be supported if required.</p><p>For example, using client certificates or assertions like SAML2 Bearer or JWT is all acceptable - the only additional requirement in this case is that a given security filter processing a specific authentication scheme maps the client credentials to an actual client_id - CXF Access Token Service will check a 
 "client_id" property on the current message context as the last resort. Note that org.apache.cxf.rs.security.oauth2.provider.ClientIdProvider can be registered with AccessTokenService to facilitate the mapping between an authenticated client and its id expected by the data provider if the container or filter based authentication can not set a "client_id" contextual property.</p><p>If a Basic authentication scheme is used and neither the container or filter has authenticated the client AccessTokenService will request a Client from the data provider and compare the Client's secret against the password found in the Basic scheme data. org.apache.cxf.rs.security.oauth2.provider.ClientSecretVerifier is available starting from CXF 3.0.3 to support Clients saving only password hashes. Its org.apache.cxf.rs.security.oauth2.provider.ClientSecretHashVerifier (calculates a SHA-256 password hash and compares it with the Client's secret) or custom implementations can be registered with AccessToke
 nService.</p><p>If a 2-way TLS is sued to authenticate a client and Client has a Base64 encoded representations of its X509Certificates available in its "applicationCertificates" property then AccessTokenService will do the additional comparison of these certificates against the ones available in the current TLS session.</p><p>&#160;</p><p>Please see <a shape="rect" href="jaxrs-oauth2-assertions.html">JAXRS OAuth2 Assertions</a> section for more information on how it may work.</p><p>&#160;</p><h1 id="JAX-RSOAuth2-UserSessionAuthenticity">User Session Authenticity</h1><p>Redirection-based Authorization Code and Implicit flows depend on end users signing in if needed during the initial redirection, challenged with the client authorization form and returning their decision. By default, CXF will enforce the user session authenticity by keeping the session state in a servlet container's HTTPSession. If the alternative storage is preferred then you can register a new <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> (available from CXF 2.6.4) with either AuthorizationCodeGrantService or ImplicitGrantService beans.</p><h3 id="JAX-RSOAuth2-Keepingthestateinthesession">Keeping the state in the session</h3><p>Note that <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> has been further updated in CXF 3.1.0 to support signing and/or encrypting some of the redirection properties that would otherwise have to be kept as HTML form hidden fields (see "Authorization Service" section).</p><p>CXF&#160; ships org.apache.cxf.rs.security.oauth2.provider.JoseSessionTokenProvider that
  can be used as a <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> which JWS-signs and/or JWE-encrypts the properties and saves the result in the session. The HTML authorization forms will only have to have an "authenticityToken" property which the provider will use to match the session signed/encryped data and decrypt and/or validate the session data.</p><h3 id="JAX-RSOAuth2-MultipleFactorVerification">Multiple Factor Verification</h3><p>Note that <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/SessionAuthenticityTokenProvider.java">SessionAuthenticityTokenProvider</a> has been updated in CXF 3.0.2 to accept request parameters and a reference to the aut
 henticated user. This allows for introducing a multiple factor session verification: when the provider created a session property it can for example sent a message to a user's mobile phone expect the authorization consent form return the sent value.</p><p>The other minor enhancement is that RedirectionBasedGrantService will check the authorization content form for the name of the form property that contains a session authentication property, using a "session_authenticity_token_param_name" property name. This allows for the 'rotation' of hidden form properties containing the actual session authenticity values.</p><h1 id="JAX-RSOAuth2-CustomizingEndUserSubjectinitialization">Customizing End User Subject initialization</h1><p>By default, redirection based authorization services will the the current CXF SecurityContext to initialize a subject representing the authenticated resource owner/end user. If the customization if needed: custom CXF filter can be used to create UserSubject and se
 t it on the message or org.apache.cxf.rs.security.oauth2.provider.SubjectCreator interface implementation can be registered with either AuthorizationCodeGrantService or ImplicitGrantService.</p><h1 id="JAX-RSOAuth2-ProtectingresourceswithOAuthfilters">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/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 clients requesting the resources.</p><p>When checking a request like this:</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/thirdPartyAccess/calendar
 Http-Method: GET
 Headers: