(Slightly) different assertions generated for WEB and ACTIVE clients

[Cantor, Scott]

On 4/18/13 4:15 PM, "Glenn Wearen" <glenn.wearen at heanet.ie> wrote:

>Many thanks, I have a ticket open with MS, and if they come up with a
>solution I'll report back  to the list

I didn't have to look at the log much. Again assuming SPNameQualifier is
implicated, the reason that the two assertions would be different can be
found in the AuthnRequest. If NameIDPolicy is specified in the request,
then I believe the qualifier will be set. If not, I don't think it will be
in certain cases (I'm not prepared to say when yet).

Your log includes some that have NameIDPolicy set and some that don't.

Looking at the IdP buildNameID method, I think I would consider what it's
doing odd, though not exactly a bug. But I wouldn't code it that way and I
would have probably changed it had I noticed.

Anyway, the difference is triggered by that difference in the request, not
the active vs. passive distinction itself. The same request in either case
would give you the same assertion back, so it's just different code on
their side that's causing it.

On the IdP resolver side, I think what you'd want to look into is whether
there's a way to forcibly set SPNameQualifier in the attribute definition
itself or the encoder attached to it. None of that code is very familiar
to me so I'm not aware of all it can do. It would seem perhaps to be a
problem to get it set to the "right" value since the right one will vary
by SP. As a horrible workaround, you might have to define a custom
attribute definition for the SAML persistent ID that is specific to MS,
and set SPNameQualifier on that. Then you could release that to MS, and
not your ordinary one.

Just grasping for suggestions.

-- Scott