nameID mutiple activationCondition per SP based on different src Attribute

[Michael Grady]

I've been "noodling on" what I hope to become an "article" on the use of NameIDs in the IdP, it seems to be the/one of the most misunderstood things to configure in the Shib IdP. But some core principles that I personally think one should follow:

 - As Scott mentions, use "order" as the driving feature, both order of the rules in saml-nameid.xml and order of the attributes in the list of attributes to potentially use as the source value for that NameID format rule.

- Do *not* use activation conditions, there are very, very few times you ever need them
  - One of the few times you might is when you need to "misuse" the Persistent format (like for Microsoft), AND you want to support the real core SAMLv2 standard compliant Persistent. (But see below, even then there is a way around that.)
  - Activation conditions have *nothing* to do with which format of NameID the IdP is trying to see if it can send, that comes down to the AuthnRequest/metadata/relying party overrides. Activation conditions only matter to decide if a given rule that produces the format needed can be used -- and there are better ways to do that then activation conditions.

- You mostly should be able to get by with ONE rule per format otherwise. You can use ordered attributes in a list of attributes to drive that rule for the format, 
  - the first attribute in the list that
     - has a value, 
     -   AND that you have a release rule for a given service
     -     will be the one used
   - Just to avoid "mistakes", in can be useful to define in your resolver "specific NameiD attributes", e.g.
     -  define NameIDuid as based on your 'uid' attribute
     -  with no encoders
     - when you want uid to be used as the source of the NameID value, release that NameIDuid attribute to the service (in the filter), and base your NameID format rules in sami-nameid.xml on those NameID-specific attributes

- Ignore what format the vendor claims they need, in 99.9% of the cases, the vendor never checks the value of the format returned, they only care about the value of the NameIF
  - Only when the AuthnRequest contains an explicit format value do you generally need to match what they say
  - Change vendor metadata to list the NaemIDFormat value you want to send to this vendor, just replace what they have
  - You can  generally make up your own formats, like make the format be the OID value for that attribute, it just must be some sort of URI
  - Never use 'unspecified' (unless you run into a very rare vendor who actually checks the format value in the response and rejects it unless the format comes back 'unspecified'.)

 - Persistent is misused a lot, not just by Microsoft, so it is not infrequent that we see folks who need to define a Persistent format rule based on actual core attribute values (and not a salted hash of such). As noted, when you want to both use Persistent as SAMLv2 intended, AND as any number of vendors actually want it, then you might end up with rules with activation conditions.
  - But even here, if you put the "misuse of Persistent format rule" first in saml-nameid.xml, before you have
        <ref bean="shibboleth.SAML2PersistentGenerator" />
    and you base that on a list of NameID=specific attributes that you have defined, lets say something like this:

        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
              p:omitQualifiers="true"
              p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
              p:attributeSourceIds="#{ {'NameIDuid','NameIDsAMAccountName','NameIDemployeeNumber', 'NameIDeduPersonPrincipalName'} }" / >
  
    Then your special case Persistent rule will ONLY get activated if a service asks for (or is 'marked for') Persistent, and if you are releasing one of those attributes to that service. Otherwise, if Persistent is asked for and none of those attributes are available, the standard Persistent rule will be used that follows your special case one.

A well thought out NameiD strategy (it would even be better if we didn't need a NameID strategy beyond Transient, but that is the not the real world unfortunately) should not need more than 3 - 6 rules total. No activation conditions, just well defined attributes. And once you have that in place, you very, very rarely need to ever modify it again. At least that is my opinion (and experience).



> On Sep 19, 2022, at 11:54 AM, Cantor, Scott via users <users at shibboleth.net> wrote:
> 
> It runs them in order, and whatever conditions are attached will execute, and the first one that's active for whichever Format it's trying to use is what will be used.
> 
> If it's not working, your conditions are simply not correct and it's picking an earlier one that shouldn't be active but is, or disallowing the one you want that should be active but isn't.
> 
> Using NOTs is a pretty good way to ensure that you get the wrong answer, particularly if they're early in the chain. You should in most cases always use positively oriented conditions, not negated ones. You want special cases up front (if RP is X, Y, Z) and then the general ones afterward that just activate by default.
> 
> It's not like filter rules where they all run and combine, only one matters.
> 	
> -- Scott

--
Michael A. Grady
IAM Architect, Unicon, Inc.