Shib IdP Proxying to another IdP help

[Cantor, Scott]

The Attribute NameFormat and the NameID Format notions are not the same thing, they're not related. The constants are not the same either. A NameID Format is the format of a NameID. An Attribute NameFormat is the format of an Attribute Name.

A NameID Format is a fairly obvious need, it allows a common element to carry many different sorts of identifiers for generality.

The "purpose" of Attribute NameFormat was to allow the contributors from IBM, Microsoft, and other frankly bad faith actors working on the standard to contaminate SAML with more complexity than it should have had to support non-interoperable use cases like calling an attribute something as simple as "first_name", which is like if LDAP short names were actually used on the wire (they're not, because that would be nuts).

Shibboleth makes using non-URI names as painful as possible because nobody should use them. The implied NameFormat in most of our software configurations is "urn:oasis:names:tc:SAML:2.0:attrname-format:uri", which I added more widely in the transcoding rule documentation as a warning.

The absence of a NameFormat in a message implies, by virtue of the rules of the standard, that the value is "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified", which is just as dumb as it sounds.

AttributeEncoders are not an appropriate vehicle for building inbound decoding rules, that's the reason the registry and transcoding layer was created. This has nothing to do with the resolver configuration, that is not where the rules for decoding are, and is no longer the intended way to do *encoding* either. It is possible to abuse the AttributeEncoder element to artificially create inbound rules but it's very awkward and confusing to do that.

If you want to leave the other IdP sending Attributes with no NameFormat, then you need to create transcoding rules that contain the desired inbound Name and NameFormat. If you want NameFormat to be empty, then you have to set the saml2.nameFormat property in the rule to "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" because that's in fact what you're receiving.

If you change the other IdP to send a NameFormat of "urn:oasis:names:tc:SAML:2.0:attrname-format:uri", then the built-in rules that match the incoming Name will fire, or at least any rules that are created can default/omit the saml2.nameFormat property.

If we're not logging it already, I'll see if the "ignored" message can be extended to log the effective NameFormat it's ignoring and not just the Name. SAML Attributes simply do not have a single part Name. Only Name and NameFormat together constitute an actual safe designation. I wish that were not the case, but I lost that argument.

-- Scott