Apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure

[Cantor, Scott]

I have nothing to contribute about Azure. The rest of your message is quite long, and full of links to documents by MS and that have been tortured to death by some piece of software, that I really find it hard to answer it well, but I can try and answer specific questions about the IdP and leave it at that.

> It's the NameID value that seems confusing to me, since this appears to have
> two sources: attribute-resolver.xml, and saml-nameid.xml together with
> saml.nameid-properties.

NameIDs can be generated out of the attribute resolver, which is a deprecated way of doing it carried over from V2, or with the newer mechanism that is very thoroughly documented in the wiki. If you ask a specific question about the newer machinery, I can answer it, but "why is my system producing X?" is not a question I can answer, and I definitely can't tell you what you *have* to do.
 
> <!-- Microsoft requires a custom Persistent ID Generator that sends the AD
> GUID -->
>    <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>         p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
>         p:attributeSourceIds="#{ {'ImmutableID'} }">
>   </bean>

That's not a typical way of producing a persistent NameID, but I imagine that's something Microsoft must be requiring (which means their system is fundamentally broken). Perhaps the source of most of your confusion is that you're trying to rationalize correct SAML behavior and guidance (us) with whatever they're doing. You can't make "it's broken" make sense, in the end.

> What is the difference between this computed value and the ImmutableID?

SAML has no construct called "ImmutableID", so I cannot relate those things for you. The reference in Shibboleth to a "computed value" is about the default way of generating the persistent NameID Format based on a hash. It is not a standard concept, it's just a term for what we did in the software for people who didn't want to use a database to store the IDs.

> Why does the unhashed base64 value of objectGUID appear as NameID in
> the SAML assertion?

Because the generator you configured is being told to directly echo an attribute value into the NameID, and mislabel it as "persistent". But if MS has a bug requiring that, then it's not a bug in your config, it's your system being deliberately told to produce a value to accomodate them. It would be entirely orthogonal to every single word in our documentation on generating persistent IDs, so you probably need to understand that fact to untie this knot.

> What happened to the hashed value set in saml-
> namid.xml? Where is it used?

It isn't involved, apparently, but it's used if you want to properly generate a SAML persistent NameID using that strategy for producing the values.

> The Shibboleth wiki page PersistentNameIDGenerationConfiguration
>  which raises more questions than it answers;

Because I think you're connecting fundamentally different things.

> advises against using objectGUID for a persistent NameID (in case
> the AD changes).

It's advising against *seeding* the computation of a hash using a value that wouldn't be stable. That has nothing to do with needing to misuse the Format by directly sending it. Apples and oranges.

> See the highlighted text below.

I don't read HTML email, so I just see text here.

> Syntactically, how is the list represented? What semantic and syntactic
> relations, if any, does idp.persistentId.sourceAttribute in saml-
> nameid.properties have to the line
> 
> p:attributeSourceIds="#{ {'ImmutableID'} }"
>
> in saml-named.xml?

They aren't related in any way. idp.persistentId.sourceAttribute is used to configure the hash seed for a computed persistentID. If you were to create your own configuration that leveraged that property for a separate purpose, that would be a local choice of course.

-- Scott