Chris,
the WSSUtility class offers also methods to retrieve the
STRs from the WSS header at the receiver side. The only thing that needs to be
done is to filter the result set for the STR with the @Usage attribute set to
the URI value, which can be achieved using the Java DOM API (*no* XPath
processor required).
- Martin
From: Christopher B Ferris
[mailto:]
Sent: Donnerstag, 20. Juli 2006
21:55
To: Raepple, Martin
Cc:
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.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email:
blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508
377 9295
"Raepple, Martin"
<> 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();
> 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 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
