Trying to release new attribute funetEduPersonLearnerId

[Scott Alexander]

Hi,

OK thank you gave some good clues were to look

And I found the reason. The bind user I'm using from the IDP doesn't seem to have enough rights to get funetEduPersonLearnerId

I'd been using a different user always with ldapsearch than what I have in ldap.properties

ldapsearch with the IDP bind user doesn't get the funetEduPersonLearnerId

but the other user does.

If it starts to work I'll keep the long namespaces for now but good hint.


Yep and a quick test with

bin/aacli.sh --configDir=conf/ --principal=testte08 -r https://idp.staging.opin.fi<https://idp.staging.opin.fi/>

and I get the correct attributes 🙂



Terveisin/Regards

Scott Alexander
Asiantuntija, järjestelmät Systems Specialist

Humak
Humanistinen ammattikorkeakoulu
University of Applied Sciences
www.humak.fi<http://www.humak.fi/>

Tel. +358 (0)50 411 9556

scott.alexander at humak.fi<mailto:scott.alexander at humak.fi>

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober via users <users at shibboleth.net>
Sent: 30 January 2025 19:22
To: users at shibboleth.net <users at shibboleth.net>
Cc: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: Trying to release new attribute funetEduPersonLearnerId

Scott Alexander via users <users at shibboleth.net> [2025-01-30 12:52 CET]:
> 2025-01-30 13:22:50,088 - DEBUG
> [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:137] - Attribute Definition 'id-urn:mace:funet.fi:attribute-def:funetEduPersonLearnerId': produced an attribute with no values

Probably not related to your current issue but note that I find
"id-urn:mace:funet.fi:attribute-def:funetEduPersonLearnerId" to be a
highly unusual and needlessly complex internal attribute id for an
AttributeDefinition within the IDP's resolver:
There's no reason to qualify internal ids with global namespaces --
that's what happens during the encoding phrase, releasing data with
the appropriate names and namespaces for the chosen protocol.
Just call it "funetEduPersonLearnerId" within your attribute resolver,
filter and possibly registry.

(And one of the benefits of using the Attribute Registry is that you
no longer have to have any of those fully qualified on-the-wire
attribute names within your resolver configuration. If you chose to
use the Attribute Registry, which you don't have to: Your
AttributeEncoder elements with your resolver are fine, you don't have
to put/move that into the Attribute Registry. In fact if you do it on
both places you'll experience the infamous "duplicate attribute
values" issue due to, well, duplicate encoding.)

Also note that if your attribute is called funetEduPersonLearnerId in
LDAP a simple entry in the Attribute Registry (for the encoding) would
suffice, you wouldn't even have to have an AttributeDefinition for it
in your resolver! You'd simply add it to your LDAP
DataConnector/@exportAttributes.

> Data connector 'AD1' resolved the following attributes:

There's no sign of an funetEduPersonLearnerId attribute there.

That seems to point to a difference in how the LDAP client within the
IDP talks to your LDAP directory vs. your (not fully representative,
is what I'm saying) test with ldapsearch.

What idp.authn.LDAP.authenticator is your IDP configured to use?
If that's adAuthenticator then the ldapsearch command cannot possibly
replicate that (as ldapsearch only supports LDAPv3, not the proprietary
extensions from M$), for example.

HTH,
-peter
--
For Consortium Member technical support, see https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C02%7C%7Cf9d227bb0de44c97abf208dd4152be08%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C638738545814531158%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c%2FQoU95xf9kLdp3EEfSjI62YOvlF94tZksuodYguhYk%3D&reserved=0<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/20250130/4558f250/attachment.htm>