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

[Cantor, Scott]

> OK thanks -- this is not at all clear from
> https://wiki.shibboleth.net/confluence/display/IDP30/Office+365
> which indicates the opposite at section 5.  Can the documentation there be
> updated to reflect this?

That is not our documentation, and I would have no idea how to change it or what to change it to. I don't have any reason to even believe it's wrong. When one is documenting an example of how to make some random thing work, the results are often going to be messy, specific to one person's way of doing things, and quite possibly hard to reconcile with any real documentation.

> Where in the wiki this documented?

You already found the NameID documentation, and it didn't help you much, so there's nothing I can really do about that, apart perhaps from noting that this page [1] is about "proper" SAML persistent NameIDs and this page [2] is about the broken thing Microsoft is doing (modulo they're using a format that is not "custom" for a value that is).

[1] https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration
[2] https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration

The properties file has nothing to do with [2], it's only used with [1]. And I'm going to get rid of that damn properties file anyway, but that's a fix for another day.

> That's not a typical way of producing a persistent NameID,
> 
> It is, up to a name change, identical to the example in
> https://wiki.shibboleth.net/confluence/display/IDP30/Office+365
> which you say is deprecated.

That is contributed material. I have no idea what it says, but the only thing that's deprecated is using the resolver to encode attributes into NameIDs. That is not anything you posted about. What Microsoft is requiring isn't deprecated, it's just plain wrong and is deeply inconsistent with our documentation and defaults. So that's kind of an inevitable mess.

> I'm sure it is, but I would like to know specifically where.

One cannot dictate from outside the system the content of a SAML NameID Format of "persistent". That value is meant to be implementation specific and opaque to an SP. An SP that requires that such a NameID carry a specific piece of data is not compliant.

> I did not invent the term "ImmutableID"--this term comes from section 4 of
> https://wiki.shibboleth.net/confluence/display/IDP30/Office+365. I will now
> copy-paste this in case there is any doubt about this fact.

I didn't say you invented it, I just said it is not a SAML concept and has no reference point in our software or official documentation. All I see there is a term identified as an Azure concept, so that is consistent with what I'm saying. I don't know what it means since I don't know Azure.

It has nothing to do with anything in our documentation, which does not include that page.

> My question, reformulated, is where did I tell it that? In saml-nameid.xml or
> in saml-nameid.properties? Or somewhere else?

You produced the resulting NameID because of what you put in saml-nameid.xml.

> Are you saying that the configuration in saml-nameid.xml sends the base64
> objectGUID, and this is unrelated to saml-nameid.properties?

Your configuration does/did, and yes, that has nothing to do with the properties file.

> OK so this configuration, which does not seem to work if the properties in
> saml-nameid.properties are left commented out, creates a persistent id that
> has nothing to do with the persistent ID specified in saml-nameid.xml.

That is simply untrue, so you have misread the situation. The only way those properties being commented out would impact something is if you deliberately uncomment the *actual* NameID generator for persistent IDs in the XML file. The generator you posted to echo the attribute directly does *not* use those properties and would not care if they were set or not.

> What does it have to do with then? I'm interested in assertions that have
> some positive existential content. How would it be used?

I don't know what you're asking there.

-- Scott