Shib IdP Proxying to another IdP help

Wed Feb 23 23:04:41 UTC 2022

Scott - 

I can make this suggestion of yours happen: " 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." 

I can change the NameFormat of IdP-NEW to "urn:oasis:names:tc:SAML:2.0:attrname-format:uri". So the IdP-NEW has a schema type that is describe as "used as the 'name' attribute in <Attributes> element.'  So if I change this to urn:oasis:names:tc:SAML:2.0:attrname-format:uri the new error is below. Do I need to put the attribute name in schema as well so it knows what to associate it with? 

2022-02-23 15:54:58,349 - 130.253.2.189 - INFO [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:443] - Profile Action ValidateSAMLAuthentication: No transcoding rule for Attribute 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri'

I also updated the attribute-resolver.xml (sticking with givenName as the example). It has that ... attrname-format:uri in it too. Is there anything else I need to add to the resolver for this part? 

   <AttributeDefinition id="givenName" xsi:type="Simple">
        <InputDataConnector ref="myActiveDirectory" attributeNames="givenName" />
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:givenName" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42" friendlyName="givenName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" encodeType="false" />
    </AttributeDefinition>

Is there something else that needs to happen to fire the built in rules? 

Thanks again,

Brent

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, February 23, 2022 11:42 AM
To: Shib Users <users at shibboleth.net>
Subject: [EXTERNAL] Re: Shib IdP Proxying to another IdP help

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

-- 
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!NCZxaNi9jForCP_SxBKJCA!BJ6QHGuhKvrMDHktgwnR3Gzd5zvetepSO9-O9kZWEO0m-4ucG4LWM80Km2OcqmwURA$ 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net