Re: FW: [ws-rx] Revised proposal #2 for i122 - i124

[Anthony Nadalin <drsecure@us.ibm.com>]

Martin, not sure who actually uses WSS4J in production/products (IBM does not), and I can tell you that this is not how the IBM stack works and this is not required of any WSS stack as there are no processing rules in WSS for STR to be available outside the WSS stack. You can't impose changes to implementations and processing rules. Actually in some cases this can open up security exposures as you are opening up the retrieval of STRs to all sorts of applications, good or bad, so I would consider the WSS4J a potential security issue based upon your note.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Raepple, Martin" <martin.raepple@sap.com>

"Raepple, Martin" <martin.raepple@sap.com>

07/20/2006 02:13 PM

To	<ws-rx@lists.oasis-open.org>
cc
Subject	FW: [ws-rx] Revised proposal #2 for i122 - i124

On the call last week there were some concerns discussed how WSS stacks will support the ORCL/SAP proposal wrt the Usage attribute on the STR. As a widely used WSS stack, I did some analysis of the Apache WSS4J Open Source project. Even though there is no native support in WSS4J to set the ".../SequenceToken" URI value to the Usage attribute of an STR, the sample code below demonstrates how this can be achieved *without* changing/knowing anything of the internal implementation of WSS4J by using the existing APIs.

The code excerpt below signs a CS message that has been passed to the security processor at the sender side:
...
WSSecSignature builder = new WSSecSignature();
Document csMsg = unsignedCSMsg.getAsDocument();
WSSecHeader secHeader = new WSSecHeader();
secHeader.insertSecurityHeader(csMsg);
Document signedCSMsg = builder.build(csMsg, crypto, secHeader);
...
Adding the Usage attribute with the URI-value to the STR as a means to unambiguously identify the referenced Token can be achieved with the following three lines of code, using the utitlity methods from the WSS4J WSSecurityUtil class:

Element csSTR = (Element)WSSecurityUtil.findElement(signedCSMsg.getFirstChild(), SecurityTokenReference.SECURITY_TOKEN_REFERENCE, WSConstants.WSSE_NS);

String prefix = WSSecurityUtil.setNamespace(csSTR, WSConstants.WSSE_NS, WSConstants.WSSE_PREFIX);
csSTR.setAttributeNS(WSConstants.WSSE_NS, prefix + ":Usage", "http://docs.oasis-open.org/ws-rx/wsrm/200602/SequenceToken");

Please note that this sample code does not require any change to the internal implementation of the SecurityTokenReference class in WSS4J.

According to page 2 / step 3 of the processing model slide deck that I posted to the list, our proposal suggests to decouple the Security and RM layer by passing only abstract handles that represent the sequence token. Again, WSS4J provides the API to obtain the token for a reference:

SecurityTokenReference newStr = new SecurityTokenReference(csSTR);
Element token = newStr.getTokenElement(signedCSMsg, null);
Generating an abstract handle for this token can be achieved by this operation:
int myUniqueSeqTokenHandle = token.hashCode();
The few lines of code above are actually the outline for the sender side implementation of an WSS4J-based interception handler in the stack processing chain. It only requires an unsigned CS message as an input parameter and returns an abstract handle of the token used to authenticate the sequence back to the RM processor.

- Martin