Subject: RE: FW: [ws-rx] Revised proposal #2 for i122 - i124
From: Christopher B Ferris [mailto:email@example.com]
Sent: Donnerstag, 20. Juli 2006 21:55
To: Raepple, Martin
Subject: Re: FW: [ws-rx] Revised proposal #2 for i122 - i124
The concern was on the receiving side... how does the RM layer ask the WSS stack for the token with the
relevant @Usage atttribute without having to have the whole SOAP message to parse through? You mentioned
using an XPath, but again, that presumes that one has a representation of the SOAP envelope that can
be processed against the XPath as opposed to the approach in which the token is right there in the CS
body (as it were) and no query is needed.
IMO, there will still be significant changes necessary to the security stack to implement a means of
askig it for the token that secures RM. That is a non-trivial change to code that is already widely deployed.
STSM, Software Group Standards Strategy
phone: +1 508 377 9295
"Raepple, Martin" <firstname.lastname@example.org> wrote on 07/20/2006 03:13:55 PM:
> 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();
> 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,
> String prefix = WSSecurityUtil.setNamespace(csSTR, WSConstants.
> WSSE_NS, WSConstants.WSSE_PREFIX);
> csSTR.setAttributeNS(WSConstants.WSSE_NS, prefix + ":Usage", "http:
> 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 thisoperation:
> 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