getting desired value into nameID

[IAM David Bantz]

A new service is correctly consuming a more or less default SAML response
from our IdP, with opaque transient nameID in the SAML Subject.
But they really want the scoped principal name (ePPN) of the user in the
nameID, and I’ve failed so far to properly configure the IdP to do so.

Their metadata as provided indicates:

        <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient
</md:NameIDFormat>

        <md:NameIDFormat>
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>

        <md:NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

        <md:NameIDFormat>
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

        <md:AssertionConsumerService Binding=
"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="
https://login.apogeenet.net/cas/login?client_name=SAML2Client0" index="0"/>
so I don’t suppose they really care about the format.

When I attempt to provide ePPN via SAML-nameid.xml config, the SAML
assertion has no nameID at all or has the default opaque transient nameID.
Tried many combinations but, as an example seeming parallel to a number of
older integrations, with the

   - multiple NameIDFormat elements removed from metadata, and
   - saml-nameid.xml configured to use ePPN for nameID & emailAddress
   format for this service,
   - relying-party.xml configured for emailAddress precedence

the subject contains unwanted long opaque transient nameID
If the format precedence is removed in relyin-party.xml the Subject
contains no nameID at all.

The only relevant message I see in logs at DEBUG is a repeat of what the
metadata is requesting, and if “unspecified” is included, a warning that
that is being ignored.

What stupid interaction/config am I spacing on?

David St Pierre Bantz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221006/130c6899/attachment.htm>