Shibboleth SP getting progressively slower

Martin Haase Martin.Haase at
Mon Nov 5 11:11:18 EST 2012

Hi Scott,

thank you very much for your precise and quick answer!

I take it that if the IdP does not support SLO, then the reverse index
is not being used at all. That's interesting.

Cheers, and thanks again,

Am 05.11.2012 16:37, schrieb Cantor, Scott:
> On 11/5/12 10:27 AM, "Martin Haase" <Martin.Haase at> wrote:
>> Sorry, my fault. What I wanted to say: *if* I maintain the index, shibd
>> seems to not remove all sessions, but only the one associated with the
>> current request.
> That depends on the logout request or process. If the request from an IdP
> references a specific SessionIndex (don't confuse that with IdP *or* SP
> session, it's neither), then the SP is obligated to remove only the one
> session. If the SP is requesting the logout, then by design it's being
> asked to remove "the session that's active" for that request.
>> Previous sessions are not removed. And the reverse
>> index for that NameId neither.
> The index is updated, it's not removed. Eventually it expires.
>> You can test this also without load, just log in twice and only call
>> /Logout for the latter. Then shibd logs a session removal only for the
>> latter session.
> That's by design, that's what that request means.
>> It's the more-common monitoring, and the customer can perhaps live with
>> the reverseIndex options you added. I'm just trying to understand what
>> calling /Logout does and if it actually makes a difference to closing
>> the browser.
> Calling /Logout from a client is asking the SP to initiate a logout for
> "the session associated with that request". There can never be multiple
> sessions associated with a request. You're talking about older sessions
> that the SP may know about, but your client has forgotten them and they
> are now orphaned.
> Orphaned sessions don't specifically get removed from the reverse index
> but the overall record in the index for a given NameID gets purged once
> the expiration for that record is reached. That's what breaks under load
> testing, it just keeps pushing out the expiration for that record.
> -- Scott
> --
> To unsubscribe from this list send an email to users-unsubscribe at

Dr. Martin Haase
DAASI International GmbH                   phone:     +49 7071 407109-6
Europaplatz 3                              Fax  :     +49 7071 407109-9
D-72072 Tübingen                           email: Martin.Haase at
Germany                                    Web  :

Directory Applications for Advanced Security and Information Management

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2345 bytes
Desc: S/MIME Kryptografische Unterschrift
Url : 

More information about the users mailing list