Issue with large HTTP headers for ECP authentication

[Daudt, Carl]

I believe we have solved our bloated cookie issue.

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 "*,+" .  As a result, a user's entire LDAP record was being populated in the cookie.  Even though the data were encrypted, the cookie nevertheless contained much more data than necessary, most of which is not used in attribute definitions and is irrelevant for SSO, and some of which is sensitive information.

We did not experience the same bloated cookie issue for non-ECP authentication (i.e., for browser based sessions that most of our services use).  We use ShibCAS for browser-based logins, and ShibCAS uses only uses only a subset of LDAP fields in the cookie.

Since our ECP connections use the Password authentication flow rather than ShibCAS, we needed to figure out a way to include minimal information being stored as cookie data.  Here is what we came up with:
(1) In ldap.properties, we changed the value of idp.authn.LDAP.returnAttributes from "*,+" to "sAMAccountName" (i.e., to the user id as stored in our LDAP directory -- some LDAP systems might use "uid").
(2) Also in ldap.properties, we added a new parameter called idp.attribute.resolver.LDAP.returnAttributes, and set it to "*,+" (although we could limit this to LDAP fields that are used in attribute-resolver.xml).
(3) We changed the ReturnAttributes line for our LDAP Data Connector in attribute-resolver.xml to the following:
   <ReturnAttributes>%{ idp.attribute.resolver.LDAP.returnAttributes }</ReturnAttributes>

By doing the three steps above, we are only using the sAMAccountName for the authentication step, and therefore sAMAccountName is the only LDAP field being made available to the the shib_idp_session_ss cookie.  Our other LDAP fields are still available for Attribute Definitions in attribute-resolver.xml.  This appears to effectively eliminate the issue with bloated cookies (and therefore bloated HTTP headers) and also eliminates the storage of unneeded sensitive information in cookies.

We are still testing our changes, but we are encouraged by the results we have seen.

Carl

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, December 10, 2018 3:08 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Issue with large HTTP headers for ECP authentication

The other "fix", really a workaround, is to turn off sessions for ECP. There's no supported way, but grepping for idp.session.enabled in the system files will locate the places the property is used to populate the activationConditions for the actions that would avoid doing anything with the cookie. You'd have to override those with scriptlets, expressions, or Java code to check for ECP (a Spring expression like "#input.isBrowserProfile()")

I'm not suggesting that but it may well work. Most of the direct property -> true/false settings are gradually being replaced with full support for plugging in conditions so just file an RFE and I'm sure we can get it included down the road.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.