Shibboleth Developers

[Adam Lantos <>]

Scott,

Thanks for the clarification!

I can retrieve the principal name and the corresponding idp session
from the logout request even when it was delivered using back-channel
binding, so the basics are working pretty well now.

However I'm not sure about multiple sessions for the same principal,
the API I used (SessionManager.getSession()) does not allow to
retrieve multiple sessions. So maybe this is not supported now, Chad
will correct me out if I were wrong.

I'm struggling a bit with commons-httpclient now, but after I'll
figure out how to properly use SSL client certificate authentication
and certificate check against SP metadata - I have the bits in place
now, it should work soon -, I'll post more details about back-channel
logout requests issued by the IdP. I expect to get my proof-of-concept
version working in the next few days.



On Sun, Jul 12, 2009 at 10:30 PM, Scott 
Cantor<>
 wrote:
> Chad La Joie wrote on 2009-07-12:
>> I'll have to discuss it with Scott.  I haven't studied the SLO profile
>> enough to say for certain what the IdP needs to retain.
>
> You have to retain the NameID used in the original assertion issued to each
> SP. That's the lookup key between the IdP and SP. The SessionIndex is
> probably needed if we're populating that to begin with in the assertion,
> because normally logout is only meant to apply to a particular set of
> sessions.
>
> Transients don't "change" within the context of a particular session, but
> are different by definition between SPs, so saving a single NameID isn't
> enough.
>
> I don't know whether we "expire" the transient ID mappings now on a
> different schedule from the assertion validity, but I probably wouldn't do
> that.
>
> But the mapping on the IdP side would have to be from NameID to session in
> order to support SP-initiated logout over back channel, if we decided to
> support that.
>
> -- Scott
>
>