cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r915661 - in /websites/production/cxf/content: cache/docs.pageCache docs/standardized-authentication-authorization.html
Date Thu, 10 Jul 2014 08:47:01 GMT
Author: buildbot
Date: Thu Jul 10 08:47:01 2014
New Revision: 915661

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/standardized-authentication-authorization.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/standardized-authentication-authorization.html
==============================================================================
--- websites/production/cxf/content/docs/standardized-authentication-authorization.html (original)
+++ websites/production/cxf/content/docs/standardized-authentication-authorization.html Thu
Jul 10 08:47:01 2014
@@ -116,7 +116,7 @@ Apache CXF -- Standardized Authenticatio
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent">    <div class="aui-message hint shadowed information-macro">
+<div id="ConfluenceContent"><p>&#160;</p><p>&#160;</p><p>&#160;</p>
   <div class="aui-message hint shadowed information-macro">
                             <span class="aui-icon icon-hint">Icon</span>
                 <div class="message-content">
                             Ideas / Proposal
@@ -125,7 +125,7 @@ Apache CXF -- Standardized Authenticatio
 <p>&#160;</p><p>CXF already supports a wide range of authentication
and authorization approaches. Unfortunately they are all configured differently and do not
integrate well with each other.</p><p>So the idea is to create one standardized
authentication / authorization flow in CXF where the modules can then fit in. There are a
lot of security frameworks out there that could be used as a basis for this. The problem is
though that each framework&#160; (like Shiro or Spring Security) uses its own mechanisms
which are not standardized. So by choosing one framework we would force our users to depend
on this.</p><p>The best standardized security framework in java is JAAS. It is
already included in Java and most security frameworks can be hooked into it. So let&#180;s
investigate what we could do with JAAS.</p><h2 id="StandardizedAuthentication/Authorization-AuthenticationusingJAAS">Authentication
using JAAS</h2><p>JAAS authentication is done by creating a LoginContext and doing
a login on
  it. Things to configure is the name of the login config and the Callback Handlers. So CXF
needs mechanisms for the user to set the config name and needs to provide CallBackHandlers
to supply credentials.</p><h2 id="StandardizedAuthentication/Authorization-CallbackHandlers">CallbackHandlers</h2><p>CXF
needs to supply different data to identify the users depending on the chosen authentication
variant.</p><p>Basic Auth: username and password from HTTP header</p><p>WS-Security
UserNameToken: Username and password from SOAP header</p><p>Spnego: Kerberos token
from HTTP header</p><p>HTTPS client cert: Certificate information</p><p>We
could simply detect what information is provided and configure the Callbackhandlers for each
information we can supply. Depending on when the login should happen we could collect CallbackHandlers
in the Message using Interceptors.</p><h2 id="StandardizedAuthentication/Authorization-JAASconfiguration">JAAS
configuration</h2><p>The JAAS configuration is suppli
 ed differently depending on the runtime CXF runs in.</p><p>Standalone: For standalone
usage the JAAS config can simply come from a file.</p><p>Servlet Container: Not
sure. Is there a standard approach for this?</p><p>Apache Karaf: Karaf already
provides a JAAS integration so we just have to configure the JAAS config name and supply a
suitable config in karaf</p><h2 id="StandardizedAuthentication/Authorization-SupplyingRoleandUserinformation">Supplying
Role and User information</h2><p>JAAS stores identity information in the JAAS
subject. The method getPrincipals returns Principal objects which can be users, roles or even
other identity information. To differentiate between roles and users there are two common
approaches.</p><ol><li>different Classes like a UserPrincipal or RolePrincipal.
There seems to be a Group interface which allows to differentiate between Users and Groups
and also allows to see group members.</li><li>prefixes. So for example roles start
with role- . There is no 
 standard for this approach</li></ol><h2 id="StandardizedAuthentication/Authorization-Authorization">Authorization</h2><p>Authorization
has very diverse requirements. So we need to make sure we integrate well with different approaches.</p><p>Generally
the idea is to base the Authorization on the JAAS login data. After a JAAS login the JAAS
subject can be retrieved in a standard way:</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[AccessControlContext
acc = AccesController.getContext();
 Subject subject = Subject.getSubject(acc);]]></script>
-</div></div><p>So the idea is that we provide certain default authorization
variants that rely on the above to retrieve authentication information in a standardized way.
So authorization is nicely decoupled from authentication and fully standards based.</p><p>This
then also provides a nice interface for users or other frameworks to access authentication
information and provide custom authorization variants.</p><h2 id="StandardizedAuthentication/Authorization-DefaultAuthorizationVariants">Default
Authorization Variants</h2><h3 id="StandardizedAuthentication/Authorization-JEEannotations">JEE
annotations</h3><p>Java EE provides some standard annotations like @RolesAllowed.
We can provide an interceptor that reads the annotations of serivce impls and provides authorization
like in a JEE container.</p><h3 id="StandardizedAuthentication/Authorization-XACMLPEP">XACML
PEP</h3><p>An XACML policy enforcement point can retrieve the JAAS login data
and do authorization against an XACML Policy D
 ecision Point (PDP).</p><h3 id="StandardizedAuthentication/Authorization-KarafrolebasedOSGiserviceAuthorization">Karaf
role based OSGi service Authorization</h3><p>Karaf 3 already supports authorization
on the OSGi service level and uses JAAS for authentication. So if we do a JAAS login in CXF
and the service impl code calls an OSGi service then the Karaf role based securtiy should
already work out of the box.</p><h2 id="StandardizedAuthentication/Authorization-Exceptionhandlingandanswergeneration">Exception
handling and answer generation</h2><p>Currently the authentication and athorization
modules often also generate the answer to the caller. It might be a good idea to decouple
this.</p><p>In the authentication and authorization we only throw a defined Exception:</p><ul><li>Failure
at Authentication: javax.security.auth.login.LoginException could also be more specific like
AccountLockedException</li><li>Failure at Authorization: org.apache.cxf.interceptor.security.AccessDeniedExcep
 tion or java.security.AccessControlException</li></ul><p>Then in the transport
like the http transport we map the exception to the defined status code and http response:</p><ul><li>LoginException:
HTTP Code 401</li><li>AccessDeniedException, AccessControlException: HTTP Code
403</li></ul><h2 id="StandardizedAuthentication/Authorization-Karafintegration">Karaf
integration</h2><p>Ideally we should integrate the new authentication / authorization
model in a way that enable the user to switch on authentication for the karaf server without
specific configurations in the user bundles that implement the services.</p><p>So
we could have a config setting for the CXF OSGi servlet to enable JAAS authentication and
set a JAAS config. This would then enable authentication for all services using the named
JAAS config from karaf. We could then also switch on the annotaion based authorization. So
users could leverage this for their service by just supplying the annotations and doing no
other config
 s on the service level.</p><p>A further approach would be to let the user configure
named features on the CXF servlet level (which are then retrieved as OSGi services). So the
user can even attach his own extensions on the server level like for ecxample integrating
a custom XACML PEP.</p><h2 id="StandardizedAuthentication/Authorization-Problems">Problems</h2><p>Doing
a full JAAS login requires to use subject.doAs to populate the AcessControlContext. This is
not possible in a CXF interceptor as the interceptor only works on a message but can not call
the next interceptor for doAs. So the question is where to do the JAAS login and the doAs?</p><h2
id="StandardizedAuthentication/Authorization-Links">Links</h2><p><a shape="rect"
class="external-link" href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html"
rel="nofollow">http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html</a></p></div>
+</div></div><p>So the idea is that we provide certain default authorization
variants that rely on the above to retrieve authentication information in a standardized way.
So authorization is nicely decoupled from authentication and fully standards based.</p><p>This
then also provides a nice interface for users or other frameworks to access authentication
information and provide custom authorization variants.</p><h2 id="StandardizedAuthentication/Authorization-DefaultAuthorizationVariants">Default
Authorization Variants</h2><h3 id="StandardizedAuthentication/Authorization-JEEannotations">JEE
annotations</h3><p>Java EE provides some standard annotations like @RolesAllowed.
We can provide an interceptor that reads the annotations of serivce impls and provides authorization
like in a JEE container.</p><h3 id="StandardizedAuthentication/Authorization-XACMLPEP">XACML
PEP</h3><p>An XACML policy enforcement point can retrieve the JAAS login data
and do authorization against an XACML Policy D
 ecision Point (PDP).</p><h2 id="StandardizedAuthentication/Authorization-SeparatingAuthorizationfromCXF">Separating
Authorization from CXF</h2><p>As authorization is not only relevant for webservices
it makes sense to keep the authorization code separate from cxf too. So one way to implement
authorization would be to put it into a blueprint extension. Of course this would cover only
OSGi and blueprint but it would be a start.</p><p>It could work similar to the
XA transaction support. Unlike in tx support we could scan all beans for security annotations
like @RolesAllowed. Then for each bean that has this annotation we could proxy it with a class
that does the security check. This would allow to have minimal xml configuration.</p><p>Another
approach is to mark beans for security checks using xml like in tx support. This variant then
would also work nicely for XACML authorization as in that case there would be no annotation
to scan for.</p><h3 id="StandardizedAuthentication/Authorizat
 ion-KarafrolebasedOSGiserviceAuthorization">Karaf role based OSGi service Authorization</h3><p>Karaf
3 already supports authorization on the OSGi service level and uses JAAS for authentication.
So if we do a JAAS login in CXF and the service impl code calls an OSGi service then the Karaf
role based securtiy should already work out of the box.We could add annotation based Authorization
to karaf code to make it even better and require less config.</p><h2 id="StandardizedAuthentication/Authorization-Exceptionhandlingandanswergeneration">Exception
handling and answer generation</h2><p>Currently the authentication and athorization
modules often also generate the answer to the caller. It might be a good idea to decouple
this.</p><p>In the authentication and authorization we only throw a defined Exception:</p><ul><li>Failure
at Authentication: javax.security.auth.login.LoginException could also be more specific like
AccountLockedException</li><li>Failure at Authorization: org.apache.cxf.in
 terceptor.security.AccessDeniedException or java.security.AccessControlException. The later
one is better for code separate from cxf as it does not depend on CXF.</li></ul><p>Then
in the transport like the http transport we map the exception to the defined status code and
http response:</p><ul><li>LoginException: HTTP Code 401</li><li>AccessDeniedException,
AccessControlException: HTTP Code 403</li></ul><p>Unfortunately CXF currently
does not handle the status code generation in the transport. The exception is already mapped
into a Fault at PhaseInterceptorChain. The Fault then holds the statusCode which is by default
500. So one simple way to do the mapping isto map from exception type to fault code in the
Fault constructor. This is not extensible but would do for the start.</p><h2 id="StandardizedAuthentication/Authorization-JAASFeature">JAAS
Feature</h2><p>The JAAS feature needs some configuration like the jaas context
name. So it makes sense to integrate it with config admin in 
 OSGi and publish it as an OSGi service. So we can keep the JAAS configuration centralized
and keep it out of each bundle.</p><p>As long as the configs are very limited
we could of course also integrate it in each bundles cxf bus. This would have the advantage
that it also works outside OSGi.</p><h2 id="StandardizedAuthentication/Authorization-Authenticationactivation">Authentication
activation</h2><p>Ideally we should integrate the new authentication / authorization
model in a way that enable the user to switch on authentication for the karaf server without
specific configurations in the user bundles that implement the services. One problem with
this very loosely coupled approach is that switching on authentication would secure all services
but perhaps some are expected to work without. The other problem is that the services might
start before the auth module and then run unsecured.</p><p>So we need a way to
mark services that need authentication. One existing way to do so is to bin
 d the auhorization Feature as an OSGi service and add it to the features "by hand". This
is a bit verbose but on the other hand it is very clear what happens.</p><p>One
other approach would be to publish the feature as a an OSGi service with a unique ID (which
is already present for features). Then we could have a new Element for cxf:bus and endpoints
like that:</p><p>&lt;namedFeatures&gt;authentication, xacmlAuthorization&lt;/namedFeatures&gt;</p><p>This
Element would mean that cxf will only publish the endpoint once both of these named features
are present and will add the features to the endpoint /bus.</p><h2 id="StandardizedAuthentication/Authorization-Problems">Problems</h2><p>Doing
a full JAAS login requires to use subject.doAs to populate the AcessControlContext. This is
not possible in a CXF interceptor as the interceptor only works on a message but can not call
the next interceptor for doAs. So the question is where to do the JAAS login and the doAs?</p><h2
id="Standardized
 Authentication/Authorization-Links">Links</h2><p><a shape="rect" class="external-link"
href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html"
rel="nofollow">http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html</a></p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message