cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r955653 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth2.html
Date Mon, 22 Jun 2015 09:47:32 GMT
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: 



Mime
View raw message