Shib IdP Proxying to another IdP help

[Brent Goebel]

Hi David - I was reloading with the attribute filter (..reload-service?id=shibboleth.AttributeFilterService and resolver (...reload-service?id=shibboleth.AttributeResolverService). Just to make sure, I was also restarting the Shibboleth service. 


Scott -- thanks for the messages.

Going off your example of givenName. We are using the URN:OID. See the entry for it in our resolver below. 

   <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" encodeType="false" />
    </AttributeDefinition>


Within the IdP-NEW originally I was sending this attribute value from IdP-NEW to Shib-IdP as 'givenName'. I also have Shib-IdP releasing that attribute 'givenName' to the SSO-enabled application. And I was getting that transcoding error message. 


So this time I tried sending the value from IdP-NEW to Shib-IdP in the urn:oid naming convention. Going off the givenName example, I updated the attribute release from IdP-NEW to Shib-IdP for givenName to be 'urn:oid:2.5.4.42'. I tried again and still see the same error but update it with the attribute name I changed it to. 


2022-02-22 15:48:16,988 - 130.253.2.189 - INFO [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:443] - Profile Action ValidateSAMLAuthentication: No transcoding rule for Attribute 'urn:oid:2.5.4.42'



-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, February 22, 2022 3:37 PM
To: Shib Users <users at shibboleth.net>
Subject: [EXTERNAL] Re: Shib IdP Proxying to another IdP help

On 2/22/22, 5:31 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>    What you call them internally to the IdP is irrelevant, and not 
> what I was talking about. You *want* them to be called the same things 
> the IdP has always called them, that's what allows them to get shipped outbound automatically by applying the same default rules in the other direction.

Concretely...take "givenName". If you want to handle it of the box, then you need it to be named with a URI in SAML of "urn:oid:2.5.4.42" and the appropriate NameFormat constant, and you want to map and process it internally as "givenName".

If you don't do that, then you need new rules.

If you want to support an alternative name inbound but standard outbound, then you add a rule that maps whatever is coming in into the internal ID of "givenName" and the outbound step will be defaulted. If you need alternative outbound, you map "givenName" to whatever else it needs to be called.

-- Scott


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