Issue with large HTTP headers for ECP authentication
Peter Schober
peter.schober at univie.ac.at
Tue Dec 11 17:59:57 EST 2018
* Daudt, Carl <crdaudt at taylor.edu> [2018-12-11 23:28]:
> We determined that with our ECP connections, the shib_idp_session_ss cookie was being populated with all of the LDAP fields available to the LDAP data connector. In attribute-resolver.xml, our Data Connector for LDAP was set using the following ReturnAttributes line:
> <ReturnAttributes>%{idp.authn.LDAP.returnAttributes}</ReturnAttributes>
> The value of idp.authn.LDAP.returnAttributes was set to "*,+" .
Note that doing the above (no matter what's the content of your
idp.authn.LDAP.returnAttributes property) is also a Bad Idea, IMO,
though fully unrelated to your issue. (Glad you figued it out, btw!)
Mostly because it likely started as a misunderstanding what the
properly was for (*not* attribute resolving as part of an LDAP
DataConnector, otherwise the example in attribute-resolver-ldap.xml
would probably be using that property), but for particular attributes
neded during /authentication/, which ldap.properties also states:
## Return attributes during authentication
idp.authn.LDAP.returnAttributes = passwordExpirationTime,loginGraceRemaining
But practically speaking it buys you nothing to put the attributes you
request via LDAP into a property file (instead of into the attribute
resolver itself), on the contrary: Doing this only prevents you from
changing and quickly reloading the requested attributes (in the
resolver) using the provided cli tool or HTTP API calls, because while
you can reload the attribute resolver you cannot reload property files.
Avoiding IDP restarts may not matter in all deployment types, of course.
-peter
More information about the users
mailing list