different assertions generated for WEB and ACTIVE clients

[Cantor, Scott]

On 1/14/13 7:15 PM, "Mauro Minella" <Mauro.Minella at microsoft.com> wrote:

>I federated my Shibboleth 2.3.8 with Office 365 following the guide on
>http://www.microsoft.com/en-us/download/details.aspx?id=35464.
>Now I need some help to identify what I should check to make sure that
>the same assertions are sent to WEB clients and ACTIVE clients, because
>right now only the WEB clients work.
> 
>In fact, WEB clients generate the 2 pieces of information (NameID and
>IDPEmail) that should be received by the relying party (Office 365),
>tracked in idp-process.log:

Your logs show clearly to me that your system is authenticating the user
with a different username in the two cases, and I would guess that is
causing your resolver configuration to generate different attribute sets
in each case, resulting in different data.

> 
>23:07:44.653 - INFO [Shibboleth-Audit:989] -
>20130114T220744Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_be3dbbab-
>3c73-4c9e-b28e-d454d3cb7e63|urn:federation:MicrosoftOnline|urn:mace:shibbo
>leth:2.0:profiles:saml2:sso|https://shibbidp.eduteamit.net/idp/shibboleth|
>urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_8b617a4a01b92a7d9830d18418
>d81a37|michela at shibbdomain.eduteamit.net|urn:oasis:names:tc:SAML:2.0:ac:cl
>asses:PasswordProtectedTransport|transientId,eduPersonScopedAffiliation,Us
>erId,eduPersonTargetedID.old,ImmutableID,eduPersonTargetedID,|WcwzuD50xEmC
>H3xsfbbeEA==|_3ef09127e94722c764188b957d125394,|

User id there internally after login is michela at shibbdomain.eduteamit.net


>When I use and ACTIVE client, instead, I receive a different token
>tracked in idp-process.log:
> 
><saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>  NameQualifier="https://shibbidp.eduteamit.net/idp/shibboleth"
>
>  SPNameQualifier="urn:federation:MicrosoftOnline">
>   _3ee899df0e468beed1e88f9d7e47a1c9 (WHERE IS THIS STRING COMING FROM?
>THE USER IS THE SAME
>michelle at shibbdomain.eduteamit.net)

No, it isn't the same, that's clear from the audit log. The NameID value
is a transient, just random. That means whatever is configured to generate
the persistent NameID isn't working. You can find documentation on how
NameID selection works in the wiki, but it isn't that crucial other than
to say that if your app can't handle transients, you should stop releasing
that attribute in the filter policy. But in this case, that will just
result in no NameID at all.

>23:09:32.303 - INFO [Shibboleth-Audit:989] -
>20130114T220932Z|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_7420ec54-1dfb-
>454f-a32c-547723139e89|urn:federation:MicrosoftOnline|urn:oasis:names:tc:S
>AML:2.0:profiles:SSO:ecp|https://shibbidp.eduteamit.net/idp/shibboleth|urn
>:oasis:names:tc:SAML:2.0:bindings:SOAP|_b72b11fb59453efbca8ff389f23d6c19|m
>ichela||transientId,eduPersonScopedAffiliation,|_3ee899df0e468beed1e88f9d7
>e47a1c9|_3462d0090ac26e82b1b681060216bc33,|

Internal user id there is michela.

Since you have to configure authentication separately in the two cases due
to limitations of the implementation, that presumably is causing the
difference.

-- Scott