NameID Definition and Usage in Shib IDP 4

[Shibboleth - Users mailing list]

Hello,

I recently upgraded from Shibboleth IDP v3.3.1 to IdP V4.0.1. As part of that upgrade, I had to change the NameID definition (globally) and the way it is mapped to the relying parties as the attribute encoder “SAML2StringNameID” is no longer supported in v4. 

For “unspecified” NameID to be mapped to employeeNumber, I am doing the following

My definition in “saml-nameid.xml”

    <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

          p:omitQualifiers="true"

          p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

          p:attributeSourceIds="#{ {'employeeNumber'} }" />

My definition in “attribute-resolver.xml”

  

    <AttributeDefinition xsi:type="Simple" id="employeeNumber">

        <InputDataConnector ref="ActiveDirectory" attributeNames="employeeNumber"/>

        <AttributeEncoder xsi:type="SAML2String" encodeType="false" name="employeeNumber"/>

    </AttributeDefinition>

My RP specific config in “relying-party.xml”

     <bean parent="RelyingPartyByName" c:relyingPartyIds="https://def.example.com">

          <property name="profileConfigurations">

              <list>

                  <bean parent="SAML2.SSO" p:securityConfiguration-ref=“def-SecurityConfig" p:signAssertions="true"

                        p:signResponses="true" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                        p:encryptAssertions="false" p:encryptNameIDs="false"/>

              </list>

          </property>

     </bean>

 

My RP specific “attribute-filter.xml” configuration

  <!-- Release to DEF -->

  <AttributeFilterPolicy id="releasetoDEF">

    <PolicyRequirementRule xsi:type="Requester" value="https://def.example.com"/>

    <AttributeRule attributeID="firstname" permitAny="true"/>

    <AttributeRule attributeID="lastname" permitAny="true"/>

    <AttributeRule attributeID="employeeNumber" permitAny="true"/>

  </AttributeFilterPolicy>

Issue: With above configuration, “employeeNumber” is sent in both SAML Subject as well as in the SAML Attribute Statement. 

Question: Am I doing this correct, If yes, Is there a way to configure an attribute mapped for NameID purpose be NOT sent in SAML Attribute statement as well ? If I am missing something, please help ! 

Thanks,

Prasanna

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

[Cantor, Scott E.]

On 1/7/21, 5:53 PM, "users on behalf of prasanna cg via users" <[hidden email] on behalf of [hidden email]> wrote:

>    Question: Am I doing this correct, If yes, Is there a way to configure an attribute mapped for NameID purpose be NOT
> sent in SAML Attribute statement as well ? If I am missing something, please help !

Yes, but why do you care?

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

[Cantor, Scott E.]

Adding....there is absolutely no circumstance in which you should ever use the unspecified NameID Format. You should refuse to do so in all cases, and there is virtually nothing that requires it.

When passing something in the NameID, the Format used should be set to whatever the attribute Name is, unless it's already a match for some other standard Format constant that would apply.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

[Shibboleth - Users mailing list]

Thanks Scott. I agree with your point. Unspecified in my example was just for illustration. The behavior is same regardless of the NameID format used. I am glad that I am doing it correct. And this is not an issue per se. But the question came out of curiosity to know if I am doing anything incorrect as I noticed this difference between v3 and v4. Thanks again for the response !

> On Jan 7, 2021, at 6:00 PM, Cantor, Scott <[hidden email]> wrote:
>
> Adding....there is absolutely no circumstance in which you should ever use the unspecified NameID Format. You should refuse to do so in all cases, and there is virtually nothing that requires it.
>
> When passing something in the NameID, the Format used should be set to whatever the attribute Name is, unless it's already a match for some other standard Format constant that would apply.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

[Cantor, Scott E.]

On 1/7/21, 6:15 PM, "users on behalf of prasanna cg via users" <[hidden email] on behalf of [hidden email]> wrote:

>    Thanks Scott. I agree with your point. Unspecified in my example was just for illustration. The behavior is same
> regardless of the NameID format used. I am glad that I am doing it correct. And this is not an issue per se. But the
> question came out of curiosity to know if I am doing anything incorrect as I noticed this difference between v3 and v4.

No. If you cared about it, the workaround is to define a custom attribute layered on top that had no default or explicit Attribute encoding rule defined and source the NameID from that instead of the original.

Or reverse it and define the standard one on top of the non-standard one. Either way it's an extra attribute definition to maintain to basically solve a non-problem.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

[Shibboleth - Users mailing list]

Thanks Scott ! I will give that a try.

Thanks,
Prasanna
(Sent from mobile device, please ignore typos)

> On Jan 7, 2021, at 6:24 PM, Cantor, Scott <[hidden email]> wrote:
>
> On 1/7/21, 6:15 PM, "users on behalf of prasanna cg via users" <[hidden email] on behalf of [hidden email]> wrote:
>
>>   Thanks Scott. I agree with your point. Unspecified in my example was just for illustration. The behavior is same
>> regardless of the NameID format used. I am glad that I am doing it correct. And this is not an issue per se. But the
>> question came out of curiosity to know if I am doing anything incorrect as I noticed this difference between v3 and v4.
>
> No. If you cared about it, the workaround is to define a custom attribute layered on top that had no default or explicit Attribute encoding rule defined and source the NameID from that instead of the original.
>
> Or reverse it and define the standard one on top of the non-standard one. Either way it's an extra attribute definition to maintain to basically solve a non-problem.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]