org.forgerock.openam.sts.soap.policy.am

Class AbstractOpenAMSessionTokenInterceptor

java.lang.Object

org.apache.cxf.phase.AbstractPhaseInterceptor<org.apache.cxf.binding.soap.SoapMessage>

org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor

org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor

org.forgerock.openam.sts.soap.policy.am.AbstractOpenAMSessionTokenInterceptor

All Implemented Interfaces:

org.apache.cxf.binding.soap.interceptor.SoapInterceptor, org.apache.cxf.interceptor.Interceptor<org.apache.cxf.binding.soap.SoapMessage>, org.apache.cxf.phase.PhaseInterceptor<org.apache.cxf.binding.soap.SoapMessage>

Direct Known Subclasses:

OpenAMSessionTokenClientInterceptor, OpenAMSessionTokenServerInterceptor

public abstract class AbstractOpenAMSessionTokenInterceptor
extends org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor

This is the base class for the OpenAMSessionTokenClientInterceptor and OpenAMSessionTokenServerInterceptor classes. It extends the AbstractTokenInterceptor, and over-rides the handleMessage method to insure that the OpenAMSessionToken interceptors are invoked, even in the presence of a wsdl file with SecurityPolicy bindings. See http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-td5754879.html for more details.

Constructor Summary

Constructors

Constructor and Description
AbstractOpenAMSessionTokenInterceptor()

Method Summary

Modifier and Type	Method and Description
void	handleMessage(org.apache.cxf.binding.soap.SoapMessage message) This method is over-ridden from the AbstractTokenInterceptor super-class.
boolean	isTLSInUse(org.apache.cxf.binding.soap.SoapMessage message) This method is called by the OpenAMSessionTokenServerInterceptor and OpenAMSessionTokenClientInterceptor classes when determining whether to assert the TransportToken.

Methods inherited from class org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor

addToken, assertTokens, assertTokens, findSecurityHeader, getPassword, getTokenStore, getUnderstoodHeaders, policyNotAsserted, policyNotAsserted, processToken

Methods inherited from class org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor

getFaultCodePrefix, getRoles, prepareStackTrace

Methods inherited from class org.apache.cxf.phase.AbstractPhaseInterceptor

addAfter, addAfter, addBefore, addBefore, getAdditionalInterceptors, getAfter, getBefore, getId, getPhase, handleFault, isGET, isRequestor, setAfter, setBefore

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Methods inherited from interface org.apache.cxf.interceptor.Interceptor

handleFault

Constructor Detail

AbstractOpenAMSessionTokenInterceptor

public AbstractOpenAMSessionTokenInterceptor()

Method Detail

handleMessage

public void handleMessage(org.apache.cxf.binding.soap.SoapMessage message)
                   throws org.apache.cxf.interceptor.Fault

This method is over-ridden from the AbstractTokenInterceptor super-class. The super-class implementation contains logic to prevent the invocation of the AbstractTokenInterceptor#addToken and #processToken methods when the PolicyBasedWSS4JOutInterceptor or PolicyBasedWSS4JInInterceptor are deployed, as in these cases, the interceptors set message state which prevents the AbstractTokenInterceptor from invoking the addToken and processToken methods of subclasses. This is because the PolicyBasedWSS4J*Interceptors are deployed when SecurityPolicy bindings are deployed, and the specific tokens (e.g. UNT, SAMLToken, KerberosToken) are handled by the higher-level SecurityPolicy-related tokens and binding which subsume the specific token types - e.g. the classes in the org.apache.cxf.ws.security.policy.model package, which include classes like the TransportToken, SignatureToken, etc. Over-riding the handleMessage in an AbstractTokenInterceptor sub-class appears to be a viable path for token types with more restricted SecurityPolicy bindings, like the OpenAMSessionToken, which will support only the Transport and 'bare' bindings. Though there are several examples - e.g. the org.apache.cxf.ws.security.wss4j.SamlTokenInterceptor, which is used in the Transport, Symmetric, and Asymmetric bindings, and is a AbstractTokenInterceptor subclass. Given the documentation state of cxf and wss4j, and the complexity of the code-base, this ambiguity cannot be resolved without significant amounts of additional time. If the OpenAMSessionAssertion must be presented over the Symmetric or Asymmetric binding, then this work will be undertaken.

Specified by:

handleMessage in interface org.apache.cxf.interceptor.Interceptor<org.apache.cxf.binding.soap.SoapMessage>

Overrides:

handleMessage in class org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor

Parameters:

message - The message corresponding to the soap invocation.

Throws:

org.apache.cxf.interceptor.Fault - if the assertTokens, addToken, or processToken methods throw an exception.

isTLSInUse

public boolean isTLSInUse(org.apache.cxf.binding.soap.SoapMessage message)

This method is called by the OpenAMSessionTokenServerInterceptor and OpenAMSessionTokenClientInterceptor classes when determining whether to assert the TransportToken. The AbstractTokenInterceptor#assertTokens is called in all four JASPI phases. The isTLSInUse implemented in the AbstractTokenInterceptor does not work in the secure-request or validate-response phases - it seems to work exclusively in the validate-request case. The OpenAMSessionToken interceptors need to assert the TransportToken in all four cases to prevent FINE warning messages concerning an unasserted TransportToken, hence this override, which works in all cases. This override will also consult the superclass method. Note however, that there is no state in the outgoing message corresponding to "http.scheme" in the server egress message, so the validate-response is not able to assert the TransportToken, and thus the FINE message warning of an unasserted TransportToken will appear. This is really the domain of the TransportBindingHandler (see http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-td5754879.html for details), so we will have to live with this error message.

Overrides:

isTLSInUse in class org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor

Parameters:

message - the SoapMessage encapsulating the STS invocation

Returns:

true if tls is being deployed

See Also:

for explanation of the approach chosen for this method.