Cryptographic nameID is longer than key length that memcache can handle

Description

The crypto nameID is significantly longer than the previous nameID format. If an SP uses memcached, the xmltooling memcached extension seems to put the nameID value in a key, which is limited to 250 characters in length. The xmltooling library fails to be able to persist the nameID value to memcache and you get a Shibboleth SP error page. Scott mentioned he'd look at using a hash to decrease the size of the nameID value.

Environment

Any that uses cryptographic nameID for stateless load balancing

Activity

Scott Cantor
October 10, 2011 at 9:38 PM

The code in the cache was already bounding names at 255 and truncating them for storage. So there's a problem with the memcache implementation, it's not supporting the required key size.

Technically, it needs to handle 255, but practically speaking, it just needs to report the allowed key size (and other sizes) via the new Capabilities interface. I have a question to the list soliciting information on that.

Scott Cantor
October 10, 2011 at 5:15 PM

Expose storage limits via API so different services can handle different maximums.

http://svn.shibboleth.net/view/cpp-xmltooling?rev=912&view=rev

Scott Cantor
August 8, 2011 at 1:16 PM

It would be good to add a warn or maybe info message to the in-memory plugin in xmltooling to flag inserts that would be too large to handle in other plugins.

Scott Cantor
August 8, 2011 at 1:15 PM

The documented context and key sizes are 255, so if the memcache implementation actually breaks at 250+, it's broken itself. Otherwise, the SP needs to be responsible for compressing the NameID down if it's going to index sessions based on the value.

Fixed

Details

Assignee

Reporter

Original estimate

Components

Fix versions

Affects versions

Created August 7, 2011 at 6:12 PM
Updated June 24, 2021 at 3:27 PM
Resolved May 2, 2012 at 8:05 PM