Trying to release new attribute funetEduPersonLearnerId

[Peter Schober]

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