[refeds] Re: SAML Logout -- giving users options .....

[Niels van Dijk]

Hi Chris, all,

During the SLO discussion at REFEDs I stated that Yaco had implemented a
(multi protocol) SLO solution into SimpleSAMLphp. Though I am sure they
could (and even may) have pulled that off, I must correct this, as it
was the good folks from RedIris that did the work I was referring to.
Jaime Pérez (now working at UNINETT) was one of the key players.

Cheers,
Niels


On 09/11/2012 10:42 PM, Chris Phillips wrote:
> Hi Steve, 
> I raised the SLO  topic at REFEDS and have my name beside it for defining what some possible work outcomes could be.  This could simply be recommendations on up to a well defined work item(s) to be done. I don't know yet but welcome capturing some use cases you talk about and others who are interested. 
>
>
> The home for now for this is:
>
> https://refeds.terena.org/index.php/REFEDS_Planning_Documents_2013
>
> Maybe a SLO topic for a BOF at i2fmm would be possible?
>
> Chris
>
> /mobile_____________________
> chris.phillips at canarie.ca
>
> On Sep 11, 2012, at 4:14 PM, "Steven Carmody" <Steven_Carmody at brown.edu> wrote:
>
>> I think we're all familiar with the the issues associated with the SAML 
>> Logout mechanism. They have been discussed for years, and there's a page 
>> on the Shib wiki that does a good job of describing the potential problems.
>>
>> Given all of that discussion, tho, Brown (like other schools, I'll 
>> guess) is seeing pressure to "do something better". Better seems to mean:
>>
>> 1) Applications could display a Logout button. When a user clicks that 
>> button, the local Application session is destroyed, and the local 
>> Shibboleth session is destroyed.
>>
>> 2) In addition, the Application could request that the Shib SP redirect 
>> the user to a specific url at the IDP associated with the Shib session. 
>> This endpoint could do some combination of actions:
>>
>> a) tell the user to quit their browser (no longer a good idea with 
>> Firefox...). Don't do anything further ....
>>
>> b) destroy the IDP session. The user will have to re-authenticate the 
>> next time they attempt to access a Shib-protected application. We are 
>> now doing this for some Applications (eg our HR system).
>>
>> c) Ask the user whether or not they want to destroy the IDP session.
>>
>> This last option appeals to me, but no one here has yet developed a 
>> design or text that could help a "regular user" make an informed decision.
>>
>> So -- does anyone have a page that implements option c) that they are 
>> willing to share ?
>>
>> Thanks in advance!
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net