...

Current version:
You may download the extension (along with documentation and setup instructions) from this direct link:
https://www.aai.dfn.de/fileadmin/tools/unimr-memcached-idp2.4-rev218rev272.tar.gz (330 341 KB - Revision 218272)

Old versions:
https://www.aai.dfn.de/fileadmin/tools/unimr-memcached.tar.gz (329 KB - Revision 151)
https://www.aai.dfn.de/fileadmin/tools/unimr-memcached-idp2.4-rev218.tar.gz (330 KB - Revision 218)

An in-depth presentation of the extension (only German, though) was held on the 9. DFN-AAI forum in Berlin (Germany) on 19-Oct-2011. It can be found at this link:
http://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt55/forum-aai-haim.pdf (811 KB)

...

(Alternatively, you may write a custom login handler which does not retain the Set loginSubject.getPrincipals() but rather creates a new java.util.HashSet<Principal>() to be stored within the Subject, containing only the authenticated username.)

Some service providers have been reported e.g. to send SAML AuthnRequest messages with very long but random message IDs (which may then end up as keys within the IdP's replay cache). However, the memcached protocol only allows for keys up to 250 bytes length. In order to handle longer keys, the memcached StorageService will take the key name and calculate the SHA512 hash instead (without collision checking, though). You may turn on INFO logging for the unimr.shib2.UniMrMemcachedStorageService to have oversized keys logged.

Setup instructions

1. Make sure your IdP nodes run behind a load balancer which sticks to the cookie "_idp_authn_lc_key" (for at least a few minutes, if you only want the login to work) or "JSESSIONID" (if you want session stickiness for Shibboleth sessions as well; it will not be sufficient to stick only to the "_idp_session" cookie). If you cannot stick to a cookie, try to stick to the user's IP address (for at least a few minutes), this should work as well.

...

    <bean id="shibboleth.StorageService"
        class="unimr.shib2.UniMrMemcachedStorageService"
        depends-on="shibboleth.LogbackLogging">
        <constructor-arg value="idp-memcached.example.org:11211" />
        <constructor-arg value="sha512" />
   < </bean>

The hostname:port of your memcached server is passed as a constructor argument and must be edited to fit your memcached setup. You may even use a space-separated list of servers here in order to spread the data over multiple instances of memcached (using a hash function). If one memcached server fails, its data is lost, but any affected session may still be alive within the local store of the IdP node which the user used to authenticate.
(This is why it is a good idea to have your load balancer stick to the "JSESSIONID" cookie.)
(A failover implementation with one active and several passive servers is not planned anymore, but you may have a look for "repcached" which is a memcached port which includes replication.)

As a second constructor argument, you may select a hashing algorithm which will be used for keys exceeding the memcached limit of 250 bytes:
a) "sha1" will calculate the 40 hex chars long SHA1 hash,
b) "sha512" (default) will calculate the 128 hex chars long SHA512 hash,
c) "sha1mixed" or "sha512mixed" will calculate the respective hash, but instead of replacing the whole key, only the end will be overwritten (so you get a semi-readable key for debugging purposes).
Implementation note: Regardless of the hashing algorithm you choose, there is no check for hash collisions. Each key will still be prepended by the StorageService's partition name (like "session", "transientId" or "replay"), and the regular keys generated by the IdP for session or transientId objects are much shorter than the memcached limit. Thus there is only a very small chance for the replay cache objects (their keys are based on the SAML message ID sent by the service provider which may in some rare cases be of unreasonable length) to get overwritten by a hash collision.

Please note: The "shibboleth.StorageServiceSweeper" in your file conf/internal.xml just stays in place, as it is needed to remove expired entries from UniMrMemcachedStorageService's local object cache.

...

8. Restart tomcat and everything should be fine.

Logging

To enable INFO, DEBUG or TRACE logging only for the new StorageService and servlet filter, add the following entries to your logging.xml configuration file:

...

16-May-2013: Revision 218 - Current Third release.
- Fixed an issue with IdP 2.4's new SLO functionality
  (the SLO removes the session from the StorageService which lead to
  a null-pointer exception in the UniMrMemcachedServletFilter when
  retrieving the session, displaying only the default Shibboleth
  error page).

04-Feb-2015: Current release.
- Added SHA1 / SHA512 hashing for oversized keys (exceeding the 250
  bytes memcached limit).

License

The IdP Memcached StorageService is released under the Apache License, Version 2.0.

...