Shibboleth Proxy to Azure: Completing logout.

Wessel, Keith kwessel at illinois.edu
Wed Jan 19 21:55:21 UTC 2022


Yes, that property will completely turn off the session layer.

We did this originally, but since we’re still using the built-in password and MFA flows for non-browser connections, we wanted to still be able to offer non-0 session length for those clients that are smart enough to store the session cookie. We ended up setting the timeout and lifetime for the SAML proxy authentication flow to 1 second (since it must be a value greater than 0). That basically disabled SSO for browsers but not for ECP clients, and we turned the session layer back on.

Keith


From: users <users-bounces at shibboleth.net> On Behalf Of Jeffrey Williams via users
Sent: Wednesday, January 19, 2022 3:46 PM
To: Shib Users <users at shibboleth.net>
Cc: Jeffrey Williams <jfwillia at uncg.edu>
Subject: Re: Shibboleth Proxy to Azure: Completing logout.



On Wed, Jan 19, 2022 at 4:01 PM Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:
On 1/19/22, 3:30 PM, "Michael Grady" <mgrady at unicon.net<mailto:mgrady at unicon.net>> wrote:

>    And if you are not trying to propagate logout anyways, another option might be you simply do not have the
> Shib IdP keep a session in the first place, and list an Azure AD logout endpoint that does not require a SAML
> logout message (just like the Shib IdP's profile/Logout endpoint) as the logout endpoint when you configure
> the SP with the Shib IdP. (Assuming Azure AD has such a logout endpoint.)

I had not considered dropping Shib IDP session creation as a whole. That seems like a pretty elegant solution to the problem.  Is configuring for that as straightforward as setting ip.session.enabled=false in idp.properties, or is there anything else that'd need to be done?

I remembered looking at a meta refresh redirect to Azure, but found that the url that Azure SSO uses is indeed SAML-based(https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-out-saml-protocol<https://urldefense.com/v3/__https:/docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-out-saml-protocol__;!!DZ3fjg!q6ZeSkLbpdguawcb70INBmzFGe8XcQyIRZFeDgqjytEe4KoOdZJ34oOCJxInFwJ9Rw$>).  Does that make this sort of logout a feature request or is there some way to craft and send the samlp:LogoutRequest in the template?


Whenever you're dealing with something not in the metadata, you have something "unmanaged", and that should never be directly pointing to a piece of software you don't control (as in, the IdP could change that URL for some reason, but a script you own lives where you decide it does).

I use /cgi-bin/logout.cgi on my IdP servers for that, and I never allow direct references to /idp/profile/Logout.

-- Scott


--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!q6ZeSkLbpdguawcb70INBmzFGe8XcQyIRZFeDgqjytEe4KoOdZJ34oOCJxKuwhKpAQ$>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


--
Jeffrey Williams
Identity & Access Engineer
Identity & Access Services
https://its.uncg.edu<https://urldefense.com/v3/__https:/its.uncg.edu__;!!DZ3fjg!q6ZeSkLbpdguawcb70INBmzFGe8XcQyIRZFeDgqjytEe4KoOdZJ34oOCJxJzo9Z7WA$>

[Image removed by sender.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220119/a4e70c6f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD0001.jpg
URL: <http://shibboleth.net/pipermail/users/attachments/20220119/a4e70c6f/attachment.jpg>


More information about the users mailing list