idpv3: what if multiple urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified ?

[Cantor, Scott]

> I was browsing the documentation of the awesome nameId genarators (
> https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationC
> onfiguration).
> It is really a welcomed job to decouple nameID from attributes.

I'm glad at least one person so far thinks this is better, I do too.

> I can't figure out how to handle multiple nameID when the format is the
> same.

There are a couple of different ways you can do it. Obviously you need to install multiple generator plugins in this case, each with the particular settings you need.

The simplest way to use them in most cases will be to create attribute defs for the sourceID that are different for each SP, and use the filter policy to limit release. If the plugin can't locate a source attribute value to use, it won't run and it should try the next one, so the filter lets you control all this as a data release matter. You don't have to attach encoders to those attribute defs, so they won't show up as SAML Attributes.

The other way, which is somewhat simpler, but involves more Spring syntax, is to attach an activationCondition property to each generator plugin that checks for the SP it's supposed to run for.

   <property name="activationCondition">
       <bean parent="shibboleth.Conditions.RelyingPartyId" c:_0=" https://sp.example.org " />
   </property>

> How can I reference the right nameID in the relyingparty
> nameIDFormatPrecedence property which expects a format (not a bean ID)?

You can't do it from there, no. That's usually a sign that something's not right in the deployment, as in this case.

-- Scott