custom nameid formats and metadata-driven config

[Mak, Steven]

Les,

My suspicion is that your main RP override is too broad and is applying to everything. And when you comment out your RP override for this one SP, it's defaulting to the broad override which is forcing "persistent OR transient".

Instead of completely commenting out the RP override, making an RP override for this one SP but excluding any NameIDFormatPreferences. Set it up for the same SAML2.SSO profile and see if that works.

- Steve

From: users <users-bounces at shibboleth.net> on behalf of Les LaCroix via users <users at shibboleth.net>
Date: Thursday, August 4, 2022 at 8:11 PM
To: Shib Users <users at shibboleth.net>
Cc: Les LaCroix <llacroix at carleton.edu>
Subject: Re: custom nameid formats and metadata-driven config
There is no NameIDPolicy in the SAML requests from this service.  The vendor-generated metadata file doesn't contain any NameIDFormat, but it's not expected to work out of the box either, as it doesn't include an entityID.  They don't care what the nameid-format specifier is.  They just need the user's username returned as the saml2:Subject.

I added "<md:NameIDFormat>urn:oid:0.9.2342.19200300.100.1.1</md:NameIDFormat>" in the SP's metadata, but my understanding now is that alone is insufficient because of the nameIDFormatPrecedence that we added to our default relying party configuration years ago.

Based on https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631679/MetadataDrivenConfiguration#NameID-Format-Selection<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631679/MetadataDrivenConfiguration*NameID-Format-Selection__;Iw!!IBzWLUs!Unp0jKZhTHptY1vdPiIAVBZ7iAet21f55_lu76YRKcAfmtWRUsi7w_G3ZSkfnmat47YVTP6igCqgq0t1$>, I thought that adding the following to the metadata would trigger the custom format.  It does not.

      <mdattr:EntityAttributes>
         <saml:Attribute Name="http://shibboleth.net/ns/profiles/nameIDFormatPrecedence<https://urldefense.com/v3/__http:/shibboleth.net/ns/profiles/nameIDFormatPrecedence__;!!IBzWLUs!Unp0jKZhTHptY1vdPiIAVBZ7iAet21f55_lu76YRKcAfmtWRUsi7w_G3ZSkfnmat47YVTP6igFD-mvyj$>"
               NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml:AttributeValue>urn:oid:0.9.2342.19200300.100.1.1</saml:AttributeValue>
         </saml:Attribute>
      </mdattr:EntityAttributes>

I do, however, trigger the custom format if I instead add the following to my relying-party.xml.

        <bean parent="RelyingPartyByName"
                    c:relyingPartyIds="#{{'http://sp.example.org/'}<https://urldefense.com/v3/__http:/sp.example.org/'*7D__;JQ!!IBzWLUs!Unp0jKZhTHptY1vdPiIAVBZ7iAet21f55_lu76YRKcAfmtWRUsi7w_G3ZSkfnmat47YVTP6igN9vEiSH$>}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO.MDDriven"
                            p:nameIDFormatPrecedence="#{{'urn:oid:0.9.2342.19200300.100.1.1'}}" />
                </list>
            </property>
        </bean>

I am using an entity attribute for this SP to set encryptAssertions=false (not shown above), and I'm really hoping to figure out how to also override nameIDFormatPrecedence with an entity attribute too.

Thanks, -Les



[https://lh6.googleusercontent.com/QEL1To3Ci_dJA1huaKzfZ0Lf4MaZlAy_f-W3vQjbyzNq_yXq_ZYGv3tuT4dkaZS_bZ5X6fZR4iKzBboZhxbCF5htZFnLNKGqmrzHsVJtsjsy0pfK5w2z0Dlq-EtZcWhv0PxBpWmR]<https://urldefense.com/v3/__http:/www.carleton.edu/__;!!IBzWLUs!Unp0jKZhTHptY1vdPiIAVBZ7iAet21f55_lu76YRKcAfmtWRUsi7w_G3ZSkfnmat47YVTP6igKQYuPko$>

Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455


On Thu, Aug 4, 2022 at 9:05 AM Mak, Steven <makst at upenn.edu<mailto:makst at upenn.edu>> wrote:
Les,

What is the service sending for a NameIDPolicy in the SAML request? If they're sending something that is not what their devs have stated they want (which is often the case), that could explain why the SP metadata route didn't work.

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220805/c8a30bf7/attachment.htm>