...

...

HTTPS

Transport-level protection of JAX-RS endpoints can be managed by underlying Servlet containers, for example, see this Tomcat SSL Configuration section.

...

It is often containers like Tomcat or frameworks like Spring Security which handle the user authentication. Sometimes you might want to do the custom authentication instead. CXF HTTP Transport adds decoded Basic Authentication credentials into an instance of AuthorizationPolicy extension and sets it on the current message. Thus the easiest way is to register a custom invoker or RequestHandler or @PreMatching ContainerRequestFilter filter which will extract a user name and password like this:

public class AuthenticationHandler implements RequestHandlerContainerRequestFilter {

    @Override
    public Responsevoid handleRequestfilter(MessageContainerRequestContext m,requestContext) ClassResourceInfothrows resourceClass)IOException {
        AuthorizationPolicyString policyauthorization = (AuthorizationPolicy)m.get(AuthorizationPolicy.classrequestContext.getHeaderString("Authorization");
        String[] usernameparts = policyauthValues.getUserNameauthorization(" ");
        String password = policy.getPassword(); 
if (parts.length != 2 || !"Basic".equals(parts[0])) {
           if requestContext.abortWith(isAuthenticatedcreateFaultResponse(username, password)) {;
            // let request to continue
return;
        }
       return null;
        }String decodedValue else= {null;
        try {
      // authentication failed, request the authetication, adddecodedValue the= realm name if needed to the value of WWW-Authenticate 
    new String(Base64Utility.decode(parts[1]));
        } catch (Base64Exception ex) {
        return Response.status(401).header("WWW-Authenticate", "Basic").build();
   requestContext.abortWith(createFaultResponse());
            }
return;
        }

}

One other thing you may want to do, after authenticating a user, is to initialize org.apache.cxf.security.SecurityContext with Principals representing the user and its roles (if available).

If you prefer using Spring Security then see how the authentication is handled in a spring-security demo.

Next, please see the Securing CXF Services section on how CXF Security interceptors can help.

Additionally check this blog entry for more information on how CXF JAX-RS wraps the CXF security interceptors with helper filters.

For example, see how a JAX-RS filter can be used to wrap CXF JAASLoginInterceptor:

        String[] namePassword = decodedValue.split(":"); 
        if (isAuthenticated(namePassword[0], namePassword[1])) {
            // let request to continue
        } else {
            // authentication failed, request the authetication, add the realm name if needed to the value of WWW-Authenticate 
            requestContext.abortWith(Response.status(401).header("WWW-Authenticate", "Basic").build());
        }
    }
    private Response createFaultResponse() {
        return Response.status(401).header("WWW-Authenticate", "Basic realm=\"service.com\"").build();
    }
 }

One other thing you may want to do, after authenticating a user, is to initialize org.apache.cxf.security.SecurityContext with Principals representing the user and its roles (if available).

If you prefer using Spring Security then see how the authentication is handled in a spring-security demo.

Next, please see the Securing CXF Services section on how CXF Security interceptors can help.

Additionally check this blog entry for more information on how CXF JAX-RS wraps the CXF security interceptors with helper filters.

For example, see how a JAX-RS filter can be used to wrap CXF JAASLoginInterceptor:

<jaxrs:server address="/jaas">
    <jaxrs:serviceBeans>
        <bean class="org.apache.cxf.systest.jaxrs.security.SecureBookStoreNoAnnotations"/>
    </jaxrs:serviceBeans>		   
    <jaxrs:providers>

<jaxrs:server address="/jaas">
    <jaxrs:serviceBeans>
        <bean class="org.apache.cxf.systest.jaxrs.security.SecureBookStoreNoAnnotations"/>
    </jaxrs:serviceBeans>		   
    <jaxrs:providers>
        <ref bean="authenticationFilter"/>
    </jaxrs:providers>
</jaxrs:server>
  
<bean id="authenticationFilter" class="org.apache.cxf.jaxrs.security.JAASAuthenticationFilter">
    <!-- Name of the JAAS Context -->
    <property name="contextName" value="BookLogin"/>
    <!-- Hint to the filter on how to have Principals representing users and roles separated 
         while initializing a SecurityContext -->
    <property name="rolePrefix" value="ROLE_"/>
        <ref bean="authenticationFilter"/>
    </jaxrs:providers>
</jaxrs:server>
  
<bean id="authenticationFilter" class="org.apache.cxf.jaxrs.security.JAASAuthenticationFilter">
    <!-- Name of the JAAS Context -->
    <property name="redirectURIcontextName" value="/login.jspBookLogin"/>
</bean>

The filter will redirect the client to "/login.jsp" if the authentication fails. If no 'redirectURI' property is set then 401 will be returned. A "realmName" property can also be set.

If the JAAS Authentication succeeds then the filter will set a SecurityContext instance on the message. This context can be used for authorization decisions.

Authorization

It is often containers like Tomcat or frameworks like Spring Security which handle user authorization, similarly to the way the authentication is handled.

CXF also provides two interceptors which make it easy to enforce authorization decisions, as described in the Securing CXF Services section.
CXF JAX-RS SimpleAuthorizingFilter can be used to wrap those interceptors and return 403 in case of failures:

    <!-- Hint to the filter on how to have Principals representing users and roles separated 
         while initializing a SecurityContext -->
    <property name="rolePrefix" value="ROLE_"/>
        
    <property name="redirectURI" value="/login.jsp"/>
</bean>

The filter will redirect the client to "/login.jsp" if the authentication fails. If no 'redirectURI' property is set then 401 will be returned. A "realmName" property can also be set.

If the JAAS Authentication succeeds then the filter will set a SecurityContext instance on the message. This context can be used for authorization decisions.

Authorization

It is often containers like Tomcat or frameworks like Spring Security which handle user authorization, similarly to the way the authentication is handled.

CXF also provides two interceptors which make it easy to enforce authorization decisions, as described in the Securing CXF Services section.
CXF JAX-RS SimpleAuthorizingFilter can be used to wrap those interceptors and return 403 in case of failures:

<jaxrs:server address="/jaas">
    <jaxrs:serviceBeans>
        <bean class="org.apache.

<jaxrs:server address="/jaas">
    <jaxrs:serviceBeans>
        <bean class="org.apache.cxf.systest.jaxrs.security.SecureBookStoreNoAnnotations"/>
    </jaxrs:serviceBeans>		   
    <jaxrs:providers>
        <ref bean="authorizationFilter"/>
    </jaxrs:providers>
</jaxrs:server>
 
<bean id="authorizationFilter" class="org.apache.cxf.jaxrs.security.SimpleAuthorizingFilter">
    <property name="methodRolesMap" ref="rolesMap"/>
</bean>
  
<util:map id="rolesMap">
    <entry key="getThatBook" value="ROLE_BOOK_OWNER"/>
    <entry key="getBook" value="ROLE_BOOK_OWNER"/>
</util:map>

...

<jaxrs:server serviceClass="org.customers.CustomerService"
    depends-on="ClientAuthHttpsSettings"
    address="https://localhost:8081/rest">

    <jaxrs:inInterceptors>
        <ref bean="basicAuthValidator"/>
    </jaxrs:inInterceptors>
  
    <jaxrs:properties>
         <entry key="ws-security.sts.client">
            <ref bean="stsclient"/>
         </entry>
    </jaxrs:properties>

</jaxrs:server>
   
<bean id="basicAuthValidator" class="org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor">
   <property name="validator">
        <bean class="org.apache.cxf.ws.security.trust.STSTokenValidator">
             <constructor-arg value="true"/>
        </bean>
   </property>
</bean>

<bean id="stsclient" class="org.apache.cxf.ws.security.trust.STSClient">
    <constructor-arg ref="cxf"/>
    <property name="wsdlLocation" value="https://localhost:8083/sts?wsdl"/>
    <property name="serviceName" value="{http://tempuri.org/}STSService"/>
    <property name="endpointName" value="{http://tempuri.org/STSServicePort"/>
</bean> 

<!-- jaxrs:server depends on this SSL configuration -->
<httpj:engine-factory id="ClientAuthHttpsSettings" bus="cxf">
  <httpj:engine port="8081">
    <httpj:tlsServerParameters>
      <sec:keyManagers keyPassword="skpass">
        <sec:keyStore type="jks" password="sspass" resource="servicestore.jks"/>
      </sec:keyManagers>
      <sec:cipherSuitesFilter>
        <sec:include>.*_EXPORT_.*</sec:include>
        <sec:include>.*_EXPORT1024_.*</sec:include>
        <sec:include>.*_WITH_DES_.*</sec:include>
        <sec:include>.*_WITH_NULL_.*</sec:include>
        <sec:exclude>.*_DH_anon_.*</sec:exclude>
        </sec:cipherSuitesFilter>
      <sec:clientAuthentication want="false" required="false"/>
   </httpj:tlsServerParameters>
</httpj:engine>
  
<!-- STSClient depends on this SSL configuration -->
<http:conduit name="https://localhost:8083/.*">
  <http:tlsClientParameters disableCNCheck="true">
    <sec:trustManagers>
      <sec:keyStore type="jks" password="sspass" resource="servicestore.jks"/>
    </sec:trustManagers>
    <sec:keyManagers keyPassword="skpass">:trustManagers>
    <sec:keyManagers keyPassword="skpass">
       <sec:keyStore type="jks" password="sspass" resource="servicestore.jks"/>
    </sec:keyManagers>
  </http:tlsClientParameters>
</http:conduit>

AuthPolicyValidatingInterceptor converts Basic Auth info into WSS4J UsernameToken and delegates to STS to validate.

Using STS to validate SAML assertions

Please see this section for more information on how STSTokenValidator can be used to validate the inbound SAML assertions.

Note about SecurityManager

If java.lang.SecurityManager is installed then you'll likely need to configure the trusted JAX-RS codebase with a 'suppressAccessChecks' permission for the injection of JAXRS context or parameter fields to succeed. For example, you may want to update a Tomcat catalina.policy with the following permission :

grant codeBase "file:${catalina.home}/webapps/yourwebapp/lib/cxf.jar" {
       <sec:keyStore type="jks" password="sspass" resource="servicestore.jks"/>
    </sec:keyManagers>
  </http:tlsClientParameters>
</http:conduit>

AuthPolicyValidatingInterceptor converts Basic Auth info into WSS4J UsernameToken and delegates to STS to validate.

Using STS to validate SAML assertions

Please see this section for more information on how STSTokenValidator can be used to validate the inbound SAML assertions.

Note about SecurityManager

If java.lang.SecurityManager is installed then you'll likely need to configure the trusted JAX-RS codebase with a 'suppressAccessChecks' permission for the injection of JAXRS context or parameter fields to succeed. For example, you may want to update a Tomcat catalina.policy with the following permission :

grant codeBase "file:${catalina.home}/webapps/yourwebapp/lib/cxf.jar" {
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

Advanced Security

...

permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

Securing JAX-RS messages

CXF provides a number of different ways to secure JAX-RS messages:

• XML messages can be secured via XML Signature and XML Encryption. See JAX-RS XML Security for more information.
• Messages can be signed and/or encryption using JOSE. In addition, authentication and authorization can be achieved using JSON Web Tokens. See JAX-RS JOSE for more information.
• Security claims can be conveyed via SAML assertions. See JAX-RS SAML for more information.
• Messages can be signed via HTTP Signature. See JAX-RS HTTP Signature for more information.

OAuth 2.0 / OpenId Connect.

CXF supports both OAuth 2.0 and OpenId Connect:

• See JAX-RS OAuth2 for information about OAuth 2.0.
• See JAX-RS OIDC for information about OpenId Connect.

Restricting large payloads

...