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

Florian Lengyel Florian.Lengyel at cuny.edu
Thu Mar 31 14:33:48 EDT 2016


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, 

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?

or with the newer mechanism that is very thoroughly documented in the wiki. 

Where in the wiki this documented?


> <!-- 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, 

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.

but I imagine that's something Microsoft must be requiring (which means their system is fundamentally broken). 

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

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. 

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.

" Configure the necessary attribute definitions and filter policy.  Only one SAML attribute, entitled "IDPEmail," should be sent.  Another attribute definition is typically required in order to send the Azure ImmutableID in the SAML Subject.  The ImmutableID attribute is site dependent, but most frequently maps to the "objectGuid" in Active Directory.  The following configuration examples are for reference only and must be modified as appropriate to your environment."


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. 

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

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.

Again I direct your attention to the Shibboleth wiki. It's essentially the configuration in https://wiki.shibboleth.net/confluence/display/IDP30/Office+365
up to renaming 'ImmutableID" with 'uMemphisAdObjectGuid'.

> 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.

What 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.

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



> 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


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.

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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list