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> </p><p> </p><p> </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> </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  (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´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><namedFeatures>authentication,
xacmlAuthorization</namedFeatures></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>
