Author: buildbot Date: Tue Jul 8 12:47:37 2014 New Revision: 915483 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 Tue Jul 8 12:47:37 2014 @@ -122,10 +122,10 @@ Apache CXF -- Standardized Authenticatio Ideas / Proposal </div> </div> -<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 variant.</p><h2 id="StandardizedAuthentication/Authorization-JAASconfiguration">JAAS configuration</h2><p>The JAAS configuration is supplied 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. Unfortunately there are no standard interfaces</li><li>prefixes. So for example roles start with role- . Again there is no standard</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"> +<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-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 configs 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><p> </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><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> <!-- Content --> </td>