Persistent NameID format with an attribute as NameID value

[Simon Lundström]

Note that you can also have different source attributes for different relying parties (this is for NameID unspecified but you get the point):
saml-nameid.xml:
    <util:list id="shibboleth.SAML2NameIDGenerators">
[…]
        <!-- Default -->
        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'eduPersonPrincipalName'} }" />

         <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
            p:attributeSourceIds="#{ {‘uid'} }">

            <!-- Sonarqube needs to get eppn for user mapping -->
            <property name="activationCondition">
               <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidates="#{{
                  ’https://example.com/vendor'
                  }}" />
            </property>
         </bean>
[…]

BR,
- Simon

On 13 Aug 2025, at 21:16, IAM David Bantz via users <users at shibboleth.net> wrote:

We did this for National Clearing House a while back which produces what you're asking for;
if redone today I'd use samlSubjectID as the basis rather than eduPersonUniqueID

and if we had control over the SP metadata, we'd do it with metadata-driven attribute release, but this SP is in InCommon.

They were adamant in requiring this particular format and value in the subject.


attribute-resolver:

 <AttributeDefinition id="nameid-persistent-eduPersonUniqueID" xsi:type="Simple" >
    <InputAttributeDefinition ref="eduPersonUniqueID" />
    <AttributeEncoder xsi:type="SAML2String" name="nameid" friendlyName="nameid"/>

  </AttributeDefinition>

relying party override:

<!-- National Student Clearing House wants "persistent" nameID  -->
    <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'https://id<https://id/>.studentclearinghouse.org/saml2/service-provider/myhub'}}">
        <property name="profileConfigurations">
            <list>
                <bean parent="SAML2.SSO"
                    p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" >
                </bean>

            </list>
        </property>

    </bean>

attribute-filter rule:

<!-- ePUID released to appear as persistent NameID -->
        <AttributeRule attributeID="nameid-persistent-eduPersonUniqueID">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="eduPersonUniqueID">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>

and here's a snippet from the SAML response:

    <saml2:Subject>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="urn:mace:incommon:alaska.edu<http://alaska.edu/>" SPNameQualifier="https://id.studentclearinghouse.org/saml2/service-provider/myh
ub">30459959 at alaska.edu<mailto:30459959 at alaska.edu></saml2:NameID>



David St Pierre Bantz
U Alaska IAM

On Wed, Aug 13, 2025 at 10:57 AM Cantor, Scott via users <users at shibboleth.net<mailto:users at shibboleth.net>> wrote:
> How would I get the IdP to use an attribute-sourced Name ID
> generator that sends an attribute as the Name ID but with a
> format of persistent?

A persistent NameID is covered by https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199507892/PersistentNameIDGenerationConfiguration

(plus the usual issue of telling the IdP to pick that Format of NameID)

The "other" option is the approach used for the pairwise-id Attribute or OpenID pairwise sub claim, which is usually done with the ComputedId connector and then taking the value and doing the usual things with the result to produce an AttributDefinition on top of that, usually via Scoped to add the domain suffix.

Neither one of those produces an Attribute with a NameID as a value, and we do not intend anybody do that anymore. That's dead code and is undocumented.

I do not believe for one second that much out there actually requires that, and I most definitely would never trust somebody's word that they did without seeing the code or testing myself.

And even then I would never do it.

-- Scott


--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

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