Conditioned attribute

[Peter Schober]

Jan Marek via users <users at shibboleth.net> [2024-07-09 09:36 CEST]:
> I've change it in this way:
> 
> idp.authn.LDAP.exportAttributes = ...

While that works it would be much clearer for yourself (or others
having to maintain that IDP or also for your future self) to avoid
making up your own settings in the "namespace" the IDP uses.
I.e., jcu_ldap_exportAttributes (or whatever) to make that clear.

> And this solved my problem. It's simply works.

Great to hear!

> > Also note that the attributes names to be listed as values for
> > idp.authn.LDAP.returnAttributes should be separated by commas, not
> > spaces.
> 
> I've found this page:
> 
> https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631576/ReturnAttributes

You where (mis-)using the property "idp.authn.LDAP.returnAttributes"
for this. Simply searching for this complete string will give this
search result (for v4, since you're still using that):
https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631612/LDAPAuthnConfiguration
There in section "Reference" after you expand the section "Properties"
you'll find this:

  Property: idp.authn.LDAP.returnAttributes
  Type: Comma-sep'd Strings
  Function: List of attributes to request during authentication

Ignore that, though, idp.authn.LDAP.returnAttributes is NOT what you
want here.

> And other question: Where I can write
> idp.authn.LDAP.returnAttributes in the definition of LDAP
> connector? I've found another else definition, but it is
> IMHO incompatible with my definition:
> 
> https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631572/LDAPConnector
> 
> in the section Spring example?

You can put Java properties into many places. Not sure why you would
be looking at the "Spring example" on that page and not the first
"Example" for conf/attribute-resolver.xml?
There you could put your custom property as the value of
DataConnector/@exportAttributes
In section "Reference" after expanding "Common XML Attributes" you'll find:
  Name: exportAttributes
  Type: Space-delimited list

*But* I'd personally not bother with moving things from the
(dynamically reloadable!) attribute resolver configuration to (not
generally reloadable!) Java properties since the latter ones are only
reliably read at startup of the JVM (i.e., of your servlet container,
commonly Jetty or Tomcat).
It may be sufficiently rare having to add another attribute to request
from the LDAP DSA but if that happens why would you prefer having to
restart the whole IDP / servlet container over just reloading the
resolver configuiration (reload-service.sh -id shibboleth.AttributeResolverService)?

Best,
-peter