Versions Compared

Old Version 19

changes.mady.by.user Sergey Beryozkin

Saved on

compared with

New Version 20

changes.mady.by.user Sergey Beryozkin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup
{span:style=font-size:2em;font-weight:bold} Securing CXF Services {span}

{toc}

h1. Secure transports

h2. HTTPS

Please see the [Configuring SSL Support|http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html] page for more information.

h1. WS-* Security  (including UsernameToken and X.509 Token profiles)

Please see the [WS-* Support|http://cxf.apache.org/docs/ws-support.html] page for more information.

h1. WS-Trust, STS

Please see the [WS-Trust|https://cwiki.apache.org/CXF20DOC/ws-trust.html] page for more information.

h1. SAML Web SSO

Please see [this blog entry|http://coheigea.blogspot.ie/2012/06/saml-web-sso-profile-support-in-apache.html] announcing the support for SAML Web SSO profile and the [SAML Web SSO|https://cwiki.apache.org/confluence/display/CXF20DOC/SAML+Web+SSO] page for more information.

h1. OAuth

Please check [OAuth2.0|http://cxf.apache.org/docs/jax-rs-oauth2.html] and [OAuth1.0|http://cxf.apache.org/docs/jax-rs-oauth.html] pages for the information about the support for OAuth 2.0 and OAuth 1.0 in CXF.

h1. Authentication

h2. JAASLoginInterceptor
 
Container or Spring Security managed authentication as well as the custom authentication are all the viable options used by CXF developers.

Starting from CXF 2.3.2 and 2.4.0 it is possible to use an org.apache.cxf.interceptor.security.JAASLoginInterceptor in order to authenticate a current user and populate a CXF SecurityContext.

Example :

{code:xml}
<jaxws:endpoint address="/soapService">
 <jaxws:inInterceptors>
   <ref bean="authenticationInterceptor"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<bean id="authenticationInterceptor" class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
   <property name="contextName" value="jaasContext"/>
   <property name="roleClassifier" value="ROLE_"/>

</bean>
<!-- 
  Similarly for JAX-RS endpoints.
  Note that org.apache.cxf.jaxrs.security.JAASAuthenticationFilter 
  can be registered as jaxrs:provider instead
-->
{code} 

The JAAS authenticator is configured with the name of the JAAS login context (the one usually specified in the JAAS configuration resource which the server is aware of). It is also configured with an optional "roleClassifier" property which is needed by the CXF SecurityContext in order to differentiate between user and role Principals. By default CXF will assume that role Principals are represented by javax.security.acl.Group instances.

In some cases objects representing a user principal and roles are implementing the same marker interface such as Principal. That can be handled like this:

{code:xml}

<bean id="authenticationInterceptor" class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
   <property name="contextName" value="jaasContext"/>
   <property name="roleClassifier" value="RolePrincipal"/>
   <property name="roleClassifierType" value="classname"/>
</bean>
<!-- Similarly for JAX-RS endpoints -->
{code} 

In this case JAASLoginInterceptor will know that the roles are represented by a class whose simple name is RolePrincipal. Note that full class names are also supported.

h2. Kerberos

Please see [this page|http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29] for the information about Spnego/Kerberos HTTPConduit client support. 

Please check the following blog entries about WS-Security Kerberos support in CXF:

[Using Kerberos with Web ServiceServices - part 1|http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html]
[Using Kerberos with Web ServiceServices - part 2|http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part.html]
[WS-Trust SPNego support in Apache CXF |http://coheigea.blogspot.com/2012/02/ws-trust-spnego-support-in-apache-cxf.html]

Please check the following [page|JAXRS Kerberos] about Kerberos support in JAX-RS.


h1. Authorization

Container or Spring Security managed authorization as well as the custom authorization are all the viable options used by CXF developers.

CXF 2.3.2 and 2.4.0 introduce org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor and org.apache.cxf.interceptor.security.SecureAnnotationsInterceptor interceptors which can help with enforcing the authorization rules.

Example :

{code:xml}
<jaxws:endpoint id="endpoint1" address="/soapService1">
 <jaxws:inInterceptors>
   <ref bean="authorizationInterceptor"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<bean id="authorizationInterceptor" class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
   <property name="methodRolesMap">
      <map>
        <entry key="addNumbers" value="ROLE_USER ROLE_ADMIN"/>
        <entry key="divideNumbers" value="ROLE_ADMIN"/>  
      </map>
   </property> 
</bean>

<jaxws:endpoint id="endpoint2" address="/soapService2" implementor="#secureBean">
 <jaxws:inInterceptors>
   <ref bean="authorizationInterceptor2"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<!-- This bean is annotated with secure annotations such as RolesAllowed -->
<bean id="secureBean" class="org.apache.cxf.tests.security.SecureService"/>

<bean id="authorizationInterceptor2" class="org.apache.cxf.interceptor.security.SecureAnnotationsInterceptor">
   <property name="securedObject" ref="secureBean"/>
</bean>

{code} 

h1. Controlling Large Request Payloads

h2. XML 
Endpoints expecting XML payloads may get [DepthRestrictingInterceptor|http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/DepthRestrictingStreamInterceptor.java] registered and configured in order to control the limits a given XML payload may not exceed. This can be useful in a variety of cases in order to protect against massive payloads which can potentially cause the denial-of-service situation or simply slow the service down a lot.

The complete number of XML elements, the number of immediate children of a given XML element may contain and the stack depth of the payload can be restricted, for example:

{code:xml}

<bean id="depthInterceptor" class="org.apache.cxf.interceptor.security.DepthRestrictingStreamInterceptor">
  <!-- Total number of elements in the XML payload -->
  <property name="elementCountThreshold" value="5000"/>

  <!-- Total number of child elements for XML elements -->
  <property name="innerElementCountThreshold" value="3000"/>

  <!-- Maximum stack depth of the XML payload -->
  <property name="innerElementLevelThreshold" value="20"/>

</bean>

<jaxws:endpoint>
  <jaxws:inInterceptors>
   <bean ref="depthInterceptor"/>
 </jaxws:inInterceptors>
<jaxws:endpoint>

<jaxrs:server>
  <jaxrs:inInterceptors>
   <bean ref="depthInterceptor"/>
 </jaxrs:inInterceptors>
<jaxrs:server>

{code}
 
When one of the limits is reached, the error is returned. JAX-WS consumers will receive 500, JAX-RS/HTTP consumers: 413.

The following system properties can also be set up for JAX-WS endpoints: "org.apache.cxf.staxutils.innerElementCountThreshold" and "org.apache.cxf.staxutils.innerElementLevelThreshold".

Please check this [section|https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Data+Bindings#JAX-RSDataBindings-ControllingLargeJAXBXMLandJSONinputpayloads] for the additional information on how JAX-RS JAXB-based providers can be configured.

h2. Multiparts
  
The "org.apache.cxf.io.CachedOutputStream.MaxSize" system property or "attachment-max-size" per-endpoint contextual property can be used to control the size of large attachments. When the limits is reached, the error is returned. JAX-WS consumers will receive 500, JAX-RS/HTTP consumers: 413.