Author: buildbot
Date: Mon Sep 23 15:56:44 2019
New Revision: 1050489
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 Sep 23 15:56:44
2019
@@ -119,11 +119,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.rbtoc1568141773313 {padding: 0px;}
-div.rbtoc1568141773313 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1568141773313 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1569254165679 {padding: 0px;}
+div.rbtoc1569254165679 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1569254165679 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1568141773313">
+/*]]>*/</style></p><div class="toc-macro rbtoc1569254165679">
<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>
@@ -484,7 +484,7 @@ ModelEncryptionSupport.decryptAccessToke
</jaxrs:serviceBeans>
</jaxrs:server>
</pre>
-</div></div><p>See this <a shape="rect" class="external-link"
href="https://github.com/apache/cxf-fediz/blob/master/services/oidc/src/main/webapp/WEB-INF/applicationContext.xml";
rel="nofollow">application context</a> for another example.</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 me
ssage 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 AccessTokenService.</p><p>Please see <a
shape="r
ect" href="jaxrs-oauth2-assertions.html">JAXRS OAuth2 Assertions</a> section
for more information on how it may work.</p><h2
id="JAX-RSOAuth2-ClientCertificateAuthentication">Client Certificate
Authentication</h2><p>If a 2-way TLS is used 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><strong>New</strong>: <a shape="rect"
class="external-link"
href="https://tools.ietf.org/html/draft-campbell-oauth-mtls-01";
rel="nofollow">Mutual TLS Profiles for OAuth2 Clients</a> is completely
supported since CXF 3.1.12. Note some parameters used in this draft may
change.</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 in
itial 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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">SessionAuthenticityTokenProvider</a> with either
AuthorizationCodeGrantService or ImplicitGrantService beans.</p><p>CXF ships <a
shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JoseSessionTokenProvider.java";
rel="nofollow">JoseSessionTokenProvider </a>which uses <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-jose.html";>CXF JOSE</a> to cre
ate a compact JWS and/or JWE sequence capturing all the data which need to be
available when the user returns an authorization form decision and this secure
sequence becomes a session token.</p><h3
id="JAX-RSOAuth2-Keepingthestateinthesession">Keeping the state in the
session</h3><p>Note that <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">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  ships <a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JoseSession
TokenProvider.java" rel="nofollow">JoseSessionTokenProvider </a>which uses <a
shape="rect" href="http://cxf.apache.org/docs/jax-rs-jose.html";>CXF JOSE</a>
that can be used as a SessionAuthenticityTokenProvider 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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">SessionAuthenticityTokenProvider</a> has been updated in CXF
3.0.2 to accept request parameters and a reference to the authenticated user.
This allows for introduci
ng 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.s
ecurity.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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/filters/OAuthRequestFilter.java";
rel="nofollow">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>See this <a shape="rect" class="external-link"
href="https://github.com/apache/cxf-fediz/blob/master/services/oidc/src/main/webapp/WEB-INF/applicationContext.xml";
rel="nofollow">application context</a> for another example.</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 me
ssage 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 AccessTokenService.</p><p>Please see <a
shape="r
ect" href="jaxrs-oauth2-assertions.html">JAXRS OAuth2 Assertions</a> section
for more information on how it may work.</p><h2
id="JAX-RSOAuth2-ClientCertificateAuthentication">Client Certificate
Authentication</h2><p>If a 2-way TLS is used 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><strong>New</strong>: <a shape="rect"
class="external-link"
href="https://tools.ietf.org/html/draft-ietf-oauth-mtls-17";
rel="nofollow">OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
Access Tokens</a> is completely supported since CXF 3.1.12. Note some
parameters used in this draft may change.</p><h1
id="JAX-RSOAuth2-UserSessionAuthenticity">User Session
Authenticity</h1><p>Redirection-based Authorization Code and Implicit flows
depend on end user
s 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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">SessionAuthenticityTokenProvider</a> with either
AuthorizationCodeGrantService or ImplicitGrantService beans.</p><p>CXF ships <a
shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JoseSessionTokenProvider.java";
rel="nofollow">JoseSessionTokenProvider </a>which uses <a shape="rect"
href="http://cxf.apache.org/docs/j
ax-rs-jose.html">CXF JOSE</a> to create a compact JWS and/or JWE sequence
capturing all the data which need to be available when the user returns an
authorization form decision and this secure sequence becomes a session
token.</p><h3 id="JAX-RSOAuth2-Keepingthestateinthesession">Keeping the state
in the session</h3><p>Note that <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">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  ships <a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/
security/oauth2/provider/JoseSessionTokenProvider.java"
rel="nofollow">JoseSessionTokenProvider </a>which uses <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-jose.html";>CXF JOSE</a> that can be
used as a SessionAuthenticityTokenProvider 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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/SessionAuthenticityTokenProvider.java";
rel="nofollow">SessionAuthenticityTokenProvider</a> has been updated in CXF
3.0.2 to accept request parameters and a reference to the authentic
ated 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 o
n 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="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/filters/OAuthRequestFilter.java";
rel="nofollow">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">
<pre class="brush: java; gutter: false; theme: Default">Address:
http://localhost:8080/services/thirdPartyAccess/calendar
Http-Method: GET
Headers:
