Shibboleth IdP is partially working with LDAP, but SAMLResponse NameID (and attributes) are missing

[o haya]

Hi Scott (et al),

FYI, I was able to get the "mail" attribute to return in the response.

The LAST problem was because I mistakenly had the following in the
attribute-filter.xml:

<AttributeFilterPolicy id="unexistingTestSP">
  <PolicyRequirementRule xsi:type="Requester" value="
https://saml.example.org" />
  <AttributeRule attributeID="uid" permitAny="true" />
  <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" />
  <AttributeRule attributeID="schacHomeOrganization" permitAny="true" />
<!-- JL - ADDED FOR BAN -->
  <AttributeRule attributeID="cn" permitAny="true" />
  <AttributeRule attributeID="*email*" permitAny="true" />        *<<<<<<
should be "mail" :(!!*
  <AttributeRule attributeID="sn" permitAny="true" />
  <AttributeRule attributeID="givenName" permitAny="true" />
</AttributeFilterPolicy>

Honestly, it took awhile to figure that out, but thanks to Scott's
comments, I eventually realized my mistake :(....

I also want to say that my longer posts have been because I've been
reacting to some earlier comments about "lack of specificity", but I will
try to keep that in mind.

Now/next, I am going to try to get the Shibboleth IdP to return both the
attributes (which I think/hope should now work) and then the NameID to the
other IdP we had in front of the Shibboleth IdP.

Thanks!

Jim


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Apr 11, 2025 at 1:53 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> > [WARNING: LONGISH post !]
>
> Dumping reams of XML and hoping somebody is willing to help you for
> free...do not mix. You think you're helping by providing context, but
> there's a balance. Just my advice.
>
> > So I am wondering if anyone might have any suggestions
> > about why the mail/emailAddress isn't being returned in the
> > SAMLResponse when the aacli command is run?
>
> Attributes in the IdP are tagged with an internal ID string that names
> them, independent of their source or eventual naming in any protocol
> message. Filtering rules are based on that ID. Attribute definitions are
> literally naming them that way. Exported data connector attributes are
> implicit attribute definitions.
>
> Using "mail" is by convention and matches the standard inetOrgPerson
> definition of the attribute type in LDAP and is mapped to the standard name
> for it in SAML to allow it to be handled withoout extra work by people who
> choose to follow the standard.
>
> Your LDAP search proves the LDAP server calls it "mail", as they all do,
> that's baked into the earliest RFCs. Nothing else you're seeing is relevant.
>
> Have the LDAP query return "mail", use the ID of "mail" in the IdP,
> release "mail" in the filter policy, and you're done.
>
> -- Scott
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250411/c137333a/attachment.htm>