cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r928304 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-oauth2.html
Date Fri, 07 Nov 2014 17:47:27 GMT
Author: buildbot
Date: Fri Nov  7 17:47:27 2014
New Revision: 928304

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 Nov  7 17:47:27 2014
@@ -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.rbtoc1415357218365 {padding: 0px;}
-div.rbtoc1415357218365 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1415357218365 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1415382419537 {padding: 0px;}
+div.rbtoc1415382419537 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1415382419537 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1415357218365">
+/*]]>*/</style></p><div class="toc-macro rbtoc1415382419537">
 <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-EndUserNameinAuthorizationForm">EndUser
Name in Authorization Form</a></li><li><a shape="rect" href="#JAX-RSOAuth2-PublicClients(Devices)">Public
Clients (Devices)</a>
@@ -139,7 +139,9 @@ div.rbtoc1415357218365 li {margin-left: 
 </li><li><a shape="rect" href="#JAX-RSOAuth2-PreAuthorizedaccesstokens">PreAuthorized
access tokens</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Pre-registeredscopes">Pre-registered
scopes</a></li><li><a shape="rect" href="#JAX-RSOAuth2-WritingOAuthDataProvider">Writing
OAuthDataProvider</a>
 <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></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>
+</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>
+</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></li><li><a shape="rect" href="#JAX-RSOAuth2-OAuth2withouttheExplicitAuthorization">OAuth2
without the Explicit Authorization</a></li><li><a shape="rect" href="#JAX-RSOAuth2-OAuthWithoutaBrowser">OAuth
Without a Browser</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Reportingerrordetails">Reporting
error details</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Designconsiderations">Design
considerations</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-ControllingtheAccesstoResourceServer">Controlling
the Access to Resource Server</a>
@@ -413,7 +415,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><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-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">
+</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">
 <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