SLO session problem

[Marc SAHIN]

Hello,

Thank you for your detailed explanation.
It was exactly the same case with CAS.

I had to add the iframe in "logout-complete.vm" for SPs which choose to 
end without SLO.
  <iframe sandbox src="logout_url" style="display:none"></iframe>

Best regards,

Marc SAHIN
Administrateur Systèmes
Pôle Système  - DSI - Université Lumière Lyon 2
04 78 77 26 66

Le 26/03/2018 à 22:49, Cameron Kerr a écrit :
>
> I have done something similar in the past with a proprietary Web SSO 
> mechanism, not with CAS (and considering Shibboleth IdP supports CAS, 
> I don’t know if there is better supported way to do with CAS)
>
> In my case, I needed to edit the logout templates (there are about 
> three of them, called at different stages; IIRC the 
> logout-propogate.vm was the most important).
>
> The Logout pages (or at least one of them) work by loading various SP 
> endpoints in iframes.
>
> So my strategy was to add another iframe manually to the page that 
> would load the other SSO’s logout page. Worked fairly well, except 
> with this SSO mechanism, it also had a bit of (unimportant) Javascript 
> that would check if it was loaded in an iframe and if so it would 
> reload the entire page, which was not helpful. I worked around that 
> issue by putting the iframe in a sandbox that disabled Javascript 
> (it’s an Ansible template, so {{ otherthing_logout_url }} would expand 
> to a URL, the important part is the ‘sandbox’ attribute.
>
> views/logout-propogate.vm
>
> <p>This should also log you out of your OTHER THING session.</p>
>
> <iframe sandbox src="{{ otherthing_logout_url }}" 
> style="display:none"></iframe>
>
> views/logout.vm
>
> #else
>
> <p><strong>#springMessageText("idp.logout.complete", "The logout 
> operation is complete, and no other services appear to have been 
> accessed during this session.")</strong></p>
>
> <!-- Complete logout from OTHER THING. It will try to reload
>
> the top-level context after it has successfully
>
> logged out; as a feature to prevent click-jacking
>
> apparently. It does that with a small javascript
>
> check to see if self is not top, and navigates the
>
>                  top context if this is not the case.
>
> I put it in a sandbox (HTML 5) to prevent that behaviour.
>
> The sandbox, by default, prevents both scripts from
>
> running and navigating the top-level context.
>
> -->
>
> <p>This should also log you out of your OTHER THING session.</p>
>
> <iframe sandbox src="{{ otherthing_logout_url }}" 
> style="display:none"></iframe>
>
> <!-- If SAML logout with no extra work to do, complete the flow by 
> adding a hidden iframe. -->
>
> #if ( $profileRequestContext.getProfileId().contains("saml2/logout") )
>
> <iframe style="display:none" src="$flowExecutionUrl&_eventId=proceed">
>
> #end
>
> #end
>
> Hope that helps,
>
> Cameron
>
> *From:*users [mailto:users-bounces at shibboleth.net] *On Behalf Of *Marc 
> SAHIN
> *Sent:* Tuesday, 27 March 2018 03:44
> *To:* Shib Users <users at shibboleth.net>
> *Subject:* SLO session problem
>
> Hello,
>
> We have activated SLO in IdP3.3 which delegates authentication process 
> to CAS server.
> However, we notice that when we sign out from web application, the 
> shibboleth session is destroyed but the CAS TGT ticket still exist.
> That cause to get access to web app with previous session.
>
> How can we ensure that both Shibboleth session and CAS ticket are 
> destroyed while signed out?
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180329/7b806a8c/attachment.html>