Shibboleth IdP is partially working with LDAP, but SAMLResponse NameID (and attributes) are missing
o haya
ohaya1001 at gmail.com
Fri Apr 11 17:25:16 UTC 2025
[WARNING: LONGISH post !]
Hi Peter (et al),
Apologies in advance, but after thinking about things overnight and after
reading and re-reading your message below, I decided that I should go
"backwards" a little, and try to get the attributes working as best I can
first, which I think is actually what you, and several others have been
recommending.
I also really liked that test setup you provided/described, with the
"unexistingTestSP", so I've been using that and modifying mostly the
attribute-filter.xml (and possibly the attribute-resolver.xml) to try to
get the aacli test to return all of the attributes I want to get in the
response.
So, after adding the attributes that I was missing (the "cn", "sn", and
"givenName" ) to the attribute-filter.xml and also to the
"exportAttribues=" parameter in the DataConnector in the
attribute-resolver.xml, I am now able to run the aacli and get all the
attributes we were looking to return, EXCEPT, I cannot seem to get the
"mail" attribute that is populated in the LDAP to be returned in the SAML
Response :(...
SIDE note: I am actually a little confused by the name for that attribute
in the LDAP server, because the "name" for that attribute is different in 3
different places/contexts:
- In the LDAP server, in the schema, it shows "emailAddress" as the
attribute name.
- However, in the LDAP Server Admin app, it appears as "E-mail", and
- when I do an ldapsearch, the attribute is being returned as an
attribute named "mail"!!
In the Shibboleth logs, when I was running the aacli test, I was seeing the
following (in both the idp-warn.log and in the idp-process.log) :
idp-process.log:2025-04-11 11:19:27,783 - 127.0.0.1 - WARN
> [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:596] -
> Attribute Resolver 'ShibbolethAttributeResolver': could not export attibute
> 'mail' from data connector 'myLDAP' since an attribute of that name already
> exists.
Then, I noticed that in the original attribute-resolver there is this
stanza:
<AttributeDefinition id="mail" xsi:type="Template">
> <InputAttributeDefinition ref="uid" />
> <Template>
> <![CDATA[
> ${uid}@example.org
> ]]>
> </Template>
> </AttributeDefinition>
>
so I commented out that stanza in the attribute-resolver.xml, and bounced
the IdP, and after commenting that out:
- I don't get the message about the mail already exists in the log files
anymore, BUT
- I am still NOT getting email, or mail, or E-mail in the response when
I run the aacli test.
Here's the current ldapsearch results for the "test1 at xxxx.com" user when I
do an ldapsearch on the LDAP (notice that the "mail" attribute is
populated):
# test1 at xxxx.com, People, xxxx.com
> dn: cn=test1 at xxxx.com,ou=People,dc=xxxx,dc=com
> mail: this_is_user_TEST1_AT_xxxx_DOT_COM_emailAddress at xxxx.com
> sn: Foo
> cn: test1 at xxxx.com
> givenName: Jack
> uid: test1 at xxxx.com
> displayName: test1 at xxxx.com
and here is the aacli run (again, notice that no mail, E-mail, or
emailAddress was returned):
/opt/shibboleth-idp/bin/aacli.sh --saml2 -n "test1 at xxxx.com" -r
> https://saml.example.org
>
>
> <?xml version="1.0" encoding="UTF-8"?><saml2:Assertion
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
> ID="_986b0f40444259bc62dc10294e6fa507"
> IssueInstant="2025-04-11T17:05:21.217Z" Version="2.0">
> <saml2:Issuer>https://idp01.xxxx.com/idp/shibboleth</saml2:Issuer>
> <saml2:Subject>
> <saml2:NameID
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="
> https://idp01.xxxx.com/idp/shibboleth" SPNameQualifier="
> https://saml.example.org
> ">AAdzZWNyZXQx+kaioGpDluWCFDQF6aweXaC7k+r5Wg/JFiMyAFasMdG0DV+X5i6FjNQkl8k28kksAh1yiWfB2i/5Y...36+9GYkYBh8ADb9eXYzZ+/5609</saml2:NameID>
> </saml2:Subject>
> <saml2:AttributeStatement>
> <saml2:Attribute FriendlyName="givenName" Name="urn:oid:2.5.4.42"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml2:AttributeValue>Jack</saml2:AttributeValue>
> </saml2:Attribute>
> <saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml2:AttributeValue>Foo</saml2:AttributeValue>
> </saml2:Attribute>
> <saml2:Attribute FriendlyName="eduPersonPrincipalName"
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml2:AttributeValue>test1 at xxxx.com@xxxx.com
> </saml2:AttributeValue>
> </saml2:Attribute>
> <saml2:Attribute FriendlyName="uid"
> Name="urn:oid:0.9.2342.19200300.100.1.1"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml2:AttributeValue>test1 at xxxx.com</saml2:AttributeValue>
> </saml2:Attribute>
> <saml2:Attribute FriendlyName="cn" Name="urn:oid:2.5.4.3"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> <saml2:AttributeValue>test1 at xxxx.com</saml2:AttributeValue>
> </saml2:Attribute>
> </saml2:AttributeStatement>
> </saml2:Assertion>
Here's the current section of the attribute-filter.xml with the added
attributes (I included both "email" and "emailAddress", because I was
hoping that one of them might work):
<!-- JL - ADD FOR PETERS METADATA TEST -->
> <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" />
> <AttributeRule attributeID="emailAddress" permitAny="true" />
> <AttributeRule attributeID="sn" permitAny="true" />
> <AttributeRule attributeID="givenName" permitAny="true" />
> </AttributeFilterPolicy>
and here's the modified line from the attribute-resolver.xml:
exportAttributes="mail displayName sn givenName departmentNumber
> employeeNumber eduPersonEntitlement eduPersonAssurance cn emailAddress">
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?
Thanks in advance!!
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 8:18 AM Peter Schober via users <
users at shibboleth.net> wrote:
> o haya via users <users at shibboleth.net> [2025-04-11 02:29 CEST]:
> > After some discussion, we want the NameID format to be emailAddress, and
> > for the source to be the "cn" attribute. Also "cn" values will be
> > emailAddress format.
>
> In /opt/shibboleth-idp/conf/saml-nameid.xml within this element:
> <util:list id="shibboleth.SAML2NameIDGenerators">
> here's what you'd add:
>
> <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>
> p:omitQualifiers="true"
>
>
> p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
> p:attributeSourceIds="#{ {'mail'} }" />
>
> Provided that the IDP has an internal attribute called 'mail' which
> holds the subject's email address from whatever data source.
> If your LDAP server has the subject's email adresss in the LDAP
> attribute "cn" (which I would find highly unusual) then you could
> either rename the attribute with your IDP attribute resolver by adding
> this to the end of your LDAP DataConnector:
> <Column columnName="cn" attributeID="mail" />
> of you'd change the above example for the NameID generation to use
> 'cn' where it currently says 'mail'.
>
> So first get the data into the IDP, then put it into a NameID.
> The final piece is making sure the NameID with the desired Format is
> sent to the SP in question. The correct and easiest way to do this is
> my amending the SP Metadata (that the IDP has on record) with the
> desired NameID Format:
>
> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
>
> HTH,
> -peter
> --
> 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/20250411/a4a17125/attachment.htm>
More information about the users
mailing list