SLO Keeping session

[Robert Lamothe]

I have two servers but I thought for clustering you needed to use idp.session.StorageService = shibboleth.MemcachedStorageService
According to the StorageConfiguration web page the only other serverside config is idp.session.StorageService = shibboleth.StorageService
I'd thought the difference was memcached allowed clustering which provides consistency through restarts and StorageService couldn't survive a restart.  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. With respect to NameID I had to change NameID from transient to email to satisfy Service Now, the only attribute they use is NameID.
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.
Regards-Bob
--
Bob Lamothe
robert_lamothe at yahoo.com
KB1BOB
603-918-6336

 

    On Wednesday, March 16, 2016 10:50 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
 

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



>Ok, so, idp.session.trackSPSessions and idp.session.secondaryServiceIndex properties were already set to true, but service side storage was not, so I set idp.session.StorageService = shibboleth.StorageService.

That has significant clustering implications. Is this a one server system? If not, that won't work.

> 
> On the SP I'm getting the same error, but on the IDP I'm now getting:
>
>2016-03-16 10:35:28,450 - INFO [net.shibboleth.idp.saml.saml2.profile.impl.ProcessLogoutRequest:315] - Profile Action ProcessLogoutRequest: No active session(s) found matching LogoutRequest

Well, the request S-N issued did not correspond to a session in the cache, generally indicating a NameID mismatch of some sort. You can turn up logging and you'll what NameID was issued to S-N and then what NameID it sent back in the LogoutRequest, that would be the starting point I guess. They have to match or the SAML protocol requires that it fail.

If that's all foreign, then you can read the SAML standard's SingleLogout protocol section, which is fairly short, and get a sense of how it works to understand how it can fail.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160316/8fb49d4c/attachment.html>