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

[Peter Schober]

* Florian Lengyel <Florian.Lengyel at cuny.edu> [2016-04-05 18:00]:
> It turns out that what Azure calls its ImmutableID (corresponding to
> the custom NameID attribute defined for Microsoft Online  in
> saml-nameid.xml) was, in our case, employeeID, not
> objectGUID. [Incidentally, I of course agree with the official
> Shibboleth documentation  that using the objectGUID "generated by an
> Active Directory is a very bad choice"
> https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration ]
> 
> After renaming the source attribute in attribute-resolver.xml to
> employeeID (and changing ldap.properties appropriately), our test
> user account was able to login to Office 365. We seem to have no
> problems with the ECP configuration.

If you're saying changing the sourceAttribute from objectGUID to
employeeID (or the other way round, doesn't matter, really) and in
both cases generating and releasing a proper persistent NameID value
(opaque; different value for every SP even for the the same subject)
much of what has been said in this thread makes very little sense to me:

It was emphasized several times that sending data that does not meet
the requirements of the SAML spec for persistent NameIDs as a
(claimed) persistent NameID was not a good idea. I.e., the statements
from this thread so far were all about (not) sending the objectGUID
/itself/ as the value, not about (not) using it as an input into a
function that eventually generates an opaque, targeted identifier.
(That's bad for totally different reasons, but fully OK as far as SAML
is concerned.)
For the same reasons one should not send an employeeID attribute
value verbatim as a persistent NameID.

But above you make it sound as if merely changing the sourceAttribute
setting (to be used as input into the persistent NameID generation
code) from objectGUID to employeeID fixed access to that service -- or
that changing from sendung objectGUID values themselfs to proper
persistent NameIDs derived from employeeID fixed it -- which I claim
is impossible: The relying party (the SAML SP) couldn't possibly
successfully recognize a subject based on a (proper) persistent NameID
that was derived from an employeeID value, versus recieving a (proper)
persistent NameID that was derived from an (base64-encoded or not)
objecGUID value. And if it's not about recognizing the subject from
the NameID any "weird" string should have given them access (correct
or not as per the SAML spec or per IDM best practices).

So either you did something else to fix "this", or you're now sending
employeeID itself (verbarim) as persistent NameID (even worse than
objectGUID from a SAML spec and data protection perspective; slightly
less worse from an Identity Management stability perspective) and that
now matches empoyeeID values already known to the service (from
out-of-band provisioning, likely). Or something else I'm not seeing atm.
-peter