SLO Keeping session

[Cantor, Scott]

On 3/16/16, 12:02 PM, "users on behalf of Robert Lamothe" <users-bounces at shibboleth.net on behalf of robert_lamothe at yahoo.com> wrote:



>I have two servers but I thought for clustering you needed to use
>idp.session.StorageService = shibboleth.MemcachedStorageService

For clustering you need to pick a solution, and understand its limitations and trade offs. That's the only one sentence answer.


The in-memory option is suitable for some limited non-replicated state but is otherwise not an option for a clustered deployment. That's why the default is now client-side, but that doesn't support SAML logout out of the box unless HTML local storage is enabled.

>According
> to the StorageConfiguration web page the only other serverside config is idp.session.StorageService = shibboleth.StorageService

The wording is a little overly pedantic. It says that's the only *bean* included. The software includes Memcache and JPA also, but there are no beans predefined for those. You have to define one and point the relevant properties at the bean name to use them.

>I'd thought the difference was memcached allowed clustering which provides consistency through restarts and StorageService couldn't survive a restart.

No, the difference is memcache is potentially shared across a cluster and in-memory cannot be and is unusable in a cluster.

>Given that I'd need to recompile my IDP to allow memcached I wanted to get it working on local memory before going through the effort of rebuilding for memcached.

You don't have to recompile the IdP to use memcache. You have to deploy and support memcache and you have to live with the implications of memcache nodes failing and understand the impact of that, like with any storage option.

> 
>With respect to NameID I had to change NameID from transient to email to satisfy Service Now, the only attribute they use is NameID.

A NameID is not an attribute. NameIDs are a special concept in SAML and they have a Format. Logout in SAML is based on messages that identify the NameID used to initiate a session, and it doesn't specifically matter which Format NameID is used, they just have to match up.

>I do have a thought though about NameID, one of our developers created an attribute in attribute-filters.xml called NameID, I wonder if it's causing confusion.

That is a horrendous idea, but aside from total confusion it has nothing to do with logout working or not working.

-- Scott