questions about ExtractUsernamePasswordFromWssToken

[Brent Putman]

On 8/1/13 3:30 PM, Cantor, Scott wrote:
>> My question was : does the WS-Security UsernameToken Profile 1.1 allow
>> more than one <Password/> element to be present ? Probably not, based
>> on the, err, spec, so I went looking for a schema, but did not find
>> one. So the next question is : how do I find out for sure ? And then,
>> should I really care ?
> I have no idea, but the answer is you'd have to read the WS-Sec username
> token profile at OASIS I suspect.

I took a look.  In short, per the schema a UsernameToken can contain
multiple Password children.  Like a lot of the WS-Security and WS-Trust
stuff, its schema is very open, essentially this:


        <xsd:sequence>
            <xsd:element name="Username" type="wsse:AttributedString"/>
            <xsd:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
        </xsd:sequence>

The Password is in fact allowed by virtue of the xsd:any wildcard, so
there can be many.  One legitimate reason you might actually have
multiple ones is that the Password element takes a Type attribute with a
URI value, implying that you might have different representations of the
same password in the message (plaintext vs. digested, different digest
algorithms, salted, etc).

Of course, an actual profile of WS-S could constrain that to one
password per token.  But the schema doesn't.

> It's "safe" because the collection of XMLObjects is pulled using
> getUnknownXMLObjects(Password.ELEMENT_NAME) and by implication if we have
> object providers registered for that element type, we assume they
> implement the Password XMLObject interface. Whether that's a good model to
> follow I don't know. I'm not that familiar with the XMLObject code and
> patterns for using them in Java, it's generally something I have to work
> on a lot because I'm used to my own code, which is somewhat different.


Strictly speaking, at the Java level it's not 100% safe, and it's always
kinda bothered me a little that we do that all over the place, i.e.
assume something looked up with QName X implements interface Y.  As far
as our own code goes it is safe, since we know we don't violate that
rule, but in general it's an iffy proposition.  But there's probably no
better alternative - at least Chad couldn't come up with one when he
designed it, and I don't have one now.  The issue is bridging the world
of XML, where types/elements are uniquely identified by QNames, and the
Java language, where types are identified by classes/interfaces.  At the
very least there has to be a translation somewhere, somehow.  I guess
you could say we took the simple(st) approach of casting via pretty
strong assumptions based on interface constants.