dev Digest, Vol 11, Issue 10

[Brent Putman]

On 5/7/12 11:01 AM, Gina Choi wrote:
>
> Following code is how do I get Assertion object out of encoded SAMLToken
> string from STS. If assertion.getDOM() doesn't change assertion token,
> unmarshalling process must change it.

The actual unmarshalling process doesn't change it (unless there's a bug
somewhere).  It's much more likely that it's already been changed by
whatever serialization/deserialization processing is going on prior to
that time.

>
> Response samlResponse = unmarshallSamlResponseToken(decodedSamlTokenStr);
> List<Assertion> assList = samlResponse.getAssertions();
>
> First line is assertion token afer decode SAML token

I really don't know exactly what that means ("decode SAML token").  If
you are doing something like getting the Response as  String and then
unmarshlling that, the very probably the mutation issue lies in exactly
how you got that String form in the first place, and/or how it's being
handled. 

>  and second line is after
> assertion.getDOM. First, it changed order of the certain attribute.

Well, attribute ordering is not significant in terms of evaluating the
signature, because the canonicalization process handles that.

>  If I
> compare further lines, it(unmarshalling?) removes some spaces as well.

Whitespace is significant in the signature evaluation, yes.  The
unmarshalling process does not remove whitespace (unless there is a
bug).  Whatever was parsed by the XML parser is what constitutes the
underlying cached DOM.


>  So, I
> can't use asserton token as actas token. Is ther anyway to get
> org.w3c.dom.Element from SAMLResonse token?

Well, taking an Element and producing from that an XMLObject is
precisely what is meant in our library by unmarshalling.  So no, there
isn't any other way other than using the unmarshallers.  As I said, I
doubt that your problem has anything to do with the unmarshalling
process, but rather with how the XML is being handled prior to that. 
This is not an uncommon problem and unintentional mutation of the XML
always turns out to be the culprit.