Issue with large HTTP headers for ECP authentication

Peter Schober peter.schober at
Tue Dec 11 17:59:57 EST 2018

* Daudt, Carl <crdaudt at> [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 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.


More information about the users mailing list