Backchannel Notify and NameID bound sessions
Harald Strack
we are using Shibboleth with the SLO extension to SSO/SLO several PHP
applications (Moodle, Mahara, ...) and it works quite well, even with
Backchannel Notify as described here
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPNotify
On application level we implemented more or less the example described
here
https://wiki.shibboleth.net/confluence/display/SHIB2/SLOWebappAdaptation
As long as a user is only logged in once from one browser / client, the
SLO works perfectly. However, when a user is logged in more then once at
the same time, e.g. with two different browsers or from two different
hosts, things getting more complex:
When /Shibboleth.sso/Logout is called from one browser, the SP collects
all sessions of the user based on the NameID and sends a SOAP message to
the <Notify> target that contains all these sessions.
An implementation of the SOAP-Handler (SLOWebappAdaptation) on
application level cannot determine the session of the actual Browser
any more and has only two choices:
1) Doing nothing, thus no SLO
2) End (delete) all the sessions, thus logging out on all the machines /
browsers of the user (real SLO!)
Can anyone give me a hint how to extend the example WSDL described at
https://wiki.shibboleth.net/confluence/display/SHIB2/SLOWebappAdaptation
in a way that all <SessionID>s are passed to
function LogoutNotification($SessionID)?
Here an example of a SOAP message containing 13 sessions (I created this
example with an automated test), the SOAP-Handler is implemented in
https://moodle.ssystems.de/auth/shibboleth/logout.php
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body>
<LogoutNotification xmlns="urn:mace:shibboleth:2.0:sp:notify"
type="global">
<SessionID>_31918281ecd4002f992062f24fd56957</SessionID>
<SessionID>_490c5593e13788ddab3c87aeda57a39b</SessionID>
<SessionID>_c731d2ebaf8924e3afbc21f3e4675676</SessionID>
<SessionID>_2985ec8cf8430c7f5d80b423515b3c44</SessionID>
<SessionID>_a532f82f107c248ea01453a9b8f47ef6</SessionID>
<SessionID>_cad53036cdae0229b6ae2f62a396cc01</SessionID>
<SessionID>_3476d1f10142eadf8aaf6d79ec1e21ec</SessionID>
<SessionID>_21a542969068aa7eb2680eb5779ac333</SessionID>
<SessionID>_d347f6de5b78c997ad8debef61417004</SessionID>
<SessionID>_6afb3f050c2b316bac40648c0d32b376</SessionID>
<SessionID>_810b47fb101b442ae7d75c070ce3f784</SessionID>
<SessionID>_7bc801d1254727ba0c710367037b3971</SessionID>
<SessionID>_fba09e423507a216766a8556596092a0</SessionID>
</LogoutNotification>
</S:Body></S:Envelope>
In shibd.log the whole SLO action looks like this:
2012-03-02 09:17:45 DEBUG Shibboleth.Logout.SAML2 [8]: session cache returned 13 sessions bound to NameID in logout request
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_31918281ecd4002f992062f24fd56957)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_490c5593e13788ddab3c87aeda57a39b)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_c731d2ebaf8924e3afbc21f3e4675676)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_2985ec8cf8430c7f5d80b423515b3c44)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_a532f82f107c248ea01453a9b8f47ef6)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_cad53036cdae0229b6ae2f62a396cc01)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_3476d1f10142eadf8aaf6d79ec1e21ec)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_21a542969068aa7eb2680eb5779ac333)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_d347f6de5b78c997ad8debef61417004)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_6afb3f050c2b316bac40648c0d32b376)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_810b47fb101b442ae7d75c070ce3f784)
2012-03-02 09:17:45 INFO Shibboleth.SessionCache [8]: removed session (_7bc801d1254727ba0c710367037b3971)
2012-03-02 09:17:45 DEBUG XMLTooling.SOAPTransport.CURL [8]: getting connection handle to https://moodle.ssystems.de/auth/shibboleth/logout.php
2012-03-02 09:17:45 DEBUG XMLTooling.SOAPTransport.CURL [8]: returning existing connection handle from pool
2012-03-02 09:17:45 DEBUG XMLTooling.SOAPClient [8]: marshalled envelope:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><LogoutNotification xmlns="urn:mace:shibboleth:2.0:sp:notify" type="global"><SessionID>_31918281ecd4002f992062f24fd56957</SessionID><SessionID>_490c5593e13788ddab3c87aeda57a39b</SessionID><SessionID>_c731d2ebaf8924e3afbc21f3e4675676</SessionID><SessionID>_2985ec8cf8430c7f5d80b423515b3c44</SessionID><SessionID>_a532f82f107c248ea01453a9b8f47ef6</SessionID><SessionID>_cad53036cdae0229b6ae2f62a396cc01</SessionID><SessionID>_3476d1f10142eadf8aaf6d79ec1e21ec</SessionID><SessionID>_21a542969068aa7eb2680eb5779ac333</SessionID><SessionID>_d347f6de5b78c997ad8debef61417004</SessionID><SessionID>_6afb3f050c2b316bac40648c0d32b376</SessionID><SessionID>_810b47fb101b442ae7d75c070ce3f784</SessionID><SessionID>_7bc801d1254727ba0c710367037b3971</SessionID><SessionID>_fba09e423507a216766a8556596092a0</SessionID></LogoutNotification></S:Body></S:Envelope>
2012-03-02 09:17:45 DEBUG XMLTooling.SOAPTransport.CURL [8]: sending SOAP message to https://moodle.ssystems.de/auth/shibboleth/logout.php
2012-03-02 09:17:46 DEBUG XMLTooling.SOAPClient [8]: received XML:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:LogoutNotificationResponse><OK/></SOAP-ENV:LogoutNotificationResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
best regards
Harald Strack
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
Tel: +49 30 2023 6071 - 1
http://www.ssystems.de
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Cantor, Scott
> all sessions of the user based on the NameID and sends a SOAP message to
> the <Notify> target that contains all these sessions.
That's how a SAML logout works, depending on the SessionIndex in the message, but when the SP initiates a logout, it only initiates a logout of the session it's being told to handle. Unless there's a bug anyway, but the code I looked at appears to be sending back channel notification with only a single session.
> Can anyone give me a hint how to extend the example WSDL described at
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/SLOWebappAdaptation
>
> in a way that all <SessionID>s are passed to
>
> function LogoutNotification($SessionID)?
Are you talking about what the SP does, or are you talking about some example of an application processing the notify messages? If it's an example, it's just to work from, just change it however you want to. If there's a WSDL (which I didn't write), then if it's not consistent with the schema the SP uses, that would be wrong, obviously.
Basically, is the SP sending the right sessions to the notify hook, or not?
-- Scott
Harald Strack
On Fri, 2012-03-02 at 15:19 +0000, Cantor, Scott wrote:
> > When /Shibboleth.sso/Logout is called from one browser, the SP collects
> > all sessions of the user based on the NameID and sends a SOAP message to
> > the <Notify> target that contains all these sessions.
>
> That's how a SAML logout works, depending on the SessionIndex in the message, but when the SP initiates a logout, it only initiates a logout of the session it's being told to handle. Unless there's a bug anyway, but the code I looked at appears to be sending back channel notification with only a single session.
No, it doesn't send only on one single session. Actually it sends as
much sessions as the user owns on this SP, here the SOAP Request from
shibd.log (13 Sessions):
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body>
<LogoutNotification xmlns="urn:mace:shibboleth:2.0:sp:notify"
type="global">
<SessionID>_31918281ecd4002f992062f24fd56957</SessionID>
<SessionID>_490c5593e13788ddab3c87aeda57a39b</SessionID>
<SessionID>_c731d2ebaf8924e3afbc21f3e4675676</SessionID>
<SessionID>_2985ec8cf8430c7f5d80b423515b3c44</SessionID>
<SessionID>_a532f82f107c248ea01453a9b8f47ef6</SessionID>
<SessionID>_cad53036cdae0229b6ae2f62a396cc01</SessionID>
<SessionID>_3476d1f10142eadf8aaf6d79ec1e21ec</SessionID>
<SessionID>_21a542969068aa7eb2680eb5779ac333</SessionID>
<SessionID>_d347f6de5b78c997ad8debef61417004</SessionID>
<SessionID>_6afb3f050c2b316bac40648c0d32b376</SessionID>
<SessionID>_810b47fb101b442ae7d75c070ce3f784</SessionID>
<SessionID>_7bc801d1254727ba0c710367037b3971</SessionID>
<SessionID>_fba09e423507a216766a8556596092a0</SessionID>
</LogoutNotification>
</S:Body></S:Envelope>
Is this allowed in the schema?
> > Can anyone give me a hint how to extend the example WSDL described at
> >
> > https://wiki.shibboleth.net/confluence/display/SHIB2/SLOWebappAdaptation
> >
> > in a way that all <SessionID>s are passed to
> >
> > function LogoutNotification($SessionID)?
>
> Are you talking about what the SP does, or are you talking about some example of an application processing the notify messages?
> If it's an example, it's just to work from, just change it however you want to.
I was just wondering if someone implemented this (workaround) already in
PHP. The difficulty here is that the SoapServer PHP implementation
cannot handle Arrays (of SessionIDs) directly as parameter - it only
passes the first element (SessionID) to the handler function. However
it's easy to implement the SOAP-Handling in PHP the simple way:
function fakeSoap ($http_post_data) {
header('Content-Type: text/xml');
preg_match_all("/<SessionID>(.*?)<\/SessionID>/", $http_post_data,
$res);
LogoutNotification( $res[1] );
//some error handling here...
echo <<<XML
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body><SOAP-ENV:LogoutNotificationResponse>
<OK/>
</SOAP-ENV:LogoutNotificationResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
XML;
}
> If there's a WSDL (which I didn't write), then if it's not consistent with the schema the SP uses, that would be wrong, obviously.
That's the question: when only one <SessionID> Element is allowed, than it's correct otherwise not.
> Basically, is the SP sending the right sessions to the notify hook, or not?
All Sessions belong to the same user. But only one of all these Sessions
has been triggered for logout - the others share only the same NameID.
I am still not sure if this is a bug or a feature...
best regards
Harald
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-un...@shibboleth.net
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Cantor, Scott
>No, it doesn't send only on one single session. Actually it sends as
>much sessions as the user owns on this SP, here the SOAP Request from
>shibd.log (13 Sessions):
I would have to dig into the code to determine what it was supposed to do.
That might be right or wrong, I don't know. I'm headed out on vacation, so
I'll get into when I get back if you file a bug. The behavior should at
least be documented.
>Is this allowed in the schema?
Yes, and you can answer that yourself, the schema is in the SP install.
>That's the question: when only one <SessionID> Element is allowed, than
>it's correct otherwise not.
The schema is clear that it allows any number. That's separate from the
question of what it will do in any given scenario. If a logout comes in
from an IdP, then there are rules specifically covering what it has to do,
and in such cases, more than one session can get terminated.
>All Sessions belong to the same user. But only one of all these Sessions
>has been triggered for logout - the others share only the same NameID.
That sounds more like an external logout initiated by the IdP, not one
initiated by the SP. But I don't know, I'll get back to it later if you
file a reminder bug.
Cantor, Scott
>On 3/3/12 1:58 AM, "Harald Strack" <hst...@ssystems.de> wrote:
>>No, it doesn't send only on one single session. Actually it sends as
>>much sessions as the user owns on this SP, here the SOAP Request from
>>shibd.log (13 Sessions):
>
>I would have to dig into the code to determine what it was supposed to do.
>That might be right or wrong, I don't know. I'm headed out on vacation, so
>I'll get into when I get back if you file a bug. The behavior should at
>least be documented.
I took a quick look before I fly out...it does not appear to trigger
notification based on all the sessions bound to a NameID when you initiate
logout at the SP. It sends a notification based on an array of size 1 with
just the session associated with the client.
My guess is you are confusing SP initiated logout with the response to a
SAML logout from an IdP. If the IdP supplies no SessionIndex to the SP,
then all sessions associated with the NameID in the LogoutRequest are
meant to be terminated, which would fit your observation.
Harald Strack
Yes, you are right. As mentioned here
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-un...@shibboleth.net
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Harald Strack
-- sorry for sending unfinished messasges, sth. wrong with my email
editor...
On Sat, 2012-03-03 at 13:53 +0000, Cantor, Scott wrote:
Yes, you are right. As mentioned here
https://wiki.aai.niif.hu/index.php/ShibIdpSLO#Session_indexing
the IdP uses the name identifier value to index the session.
Additionally there seems to be no way to configure the IdP to send the
SessionIndex.
However, this flow ends up in only one deleted IdP session and all
deleted SP-Sessions that share the same NameID. Thus, a user is only
logged out from IdP and SP on the client / browser where he initiated
the logut. On all other clients / browsers only the SP session has been
deleted but the IdP session is still alive and the user will be SSO'ed
again. This may confuse our users...
Is there a way to either
1 tell the IdP to delete all sessions for a given NameID on Logout?
2 tell the SP to contact the IdP again (back channel?) whenever SP sessions getting this way?
br & happy holidays
Harald
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-un...@shibboleth.net
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Chad La Joie
> 1 tell the IdP to delete all sessions for a given NameID on Logout?
That's something you'd have to ask the Hungarians since the Shibboleth
IdP doesn't support logout.
> 2 tell the SP to contact the IdP again (back channel?) whenever SP sessions getting this way?
No. Once the SP has dumped the session(s) it's gone, along with the
data associated with it.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Kristof Bajnok
>> My guess is you are confusing SP initiated logout with the response to a
>> SAML logout from an IdP. If the IdP supplies no SessionIndex to the SP,
>> then all sessions associated with the NameID in the LogoutRequest are
>> meant to be terminated, which would fit your observation.
> Yes, you are right. As mentioned here
>
> https://wiki.aai.niif.hu/index.php/ShibIdpSLO#Session_indexing
>
> the IdP uses the name identifier value to index the session.
> Additionally there seems to be no way to configure the IdP to send the
> SessionIndex.
>
> However, this flow ends up in only one deleted IdP session and all
> deleted SP-Sessions that share the same NameID. Thus, a user is only
> logged out from IdP and SP on the client / browser where he initiated
> the logut. On all other clients / browsers only the SP session has been
> deleted but the IdP session is still alive and the user will be SSO'ed
> again. This may confuse our users...
>
> Is there a way to either
>
> 1 tell the IdP to delete all sessions for a given NameID on Logout?
No, I think it's currently not possible by the current SLO
implementation, though I haven't looked up the code. Because the v2 SLO
patch is not actively maintained (it's just updated for the upcoming IdP
releases), it won't be fixed until at least IdPv3.
The problem is that currently it's not possible to clear _all_ IdP
sessions at the IdP. Still I'm wondering how the process should be done.
How can one user's IdP sessions be bound together? I suspect, the
principal name might be different across sessions (it's bound to the
authentication), but is there any other key for this purpose? Will this
be possible with v3?
Adam Lantos has been playing with it while experimenting with
administrative logout, but as far as I can remember, this was the main
point he didn't go on too far.
> 2 tell the SP to contact the IdP again (back channel?) whenever SP sessions getting this way?
It's not allowed by the SAML specification.
Kristof
Chad La Joie
On Mon, Mar 5, 2012 at 06:09, Kristof Bajnok <baj...@niif.hu> wrote:
> The problem is that currently it's not possible to clear _all_ IdP
> sessions at the IdP. Still I'm wondering how the process should be done.
> How can one user's IdP sessions be bound together? I suspect, the
> principal name might be different across sessions (it's bound to the
> authentication), but is there any other key for this purpose? Will this
> be possible with v3?
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Kristof Bajnok
> No, v3 will only destroy the session associated with given logout request..
I think this is the answer to the OP.
Probably an RFE could help keeping track of this limitation, but I can
agree with the Shib devs that your multiple IdP sessions + shared nameid
+ SLO scenario is quite special, and concerning the fundamental changes
it seems to require, it will probably get low priority.
> On Mon, Mar 5, 2012 at 06:09, Kristof Bajnok <baj...@niif.hu> wrote:
>> The problem is that currently it's not possible to clear _all_ IdP
>> sessions at the IdP. Still I'm wondering how the process should be done.
>> How can one user's IdP sessions be bound together? I suspect, the
>> principal name might be different across sessions (it's bound to the
>> authentication), but is there any other key for this purpose? Will this
>> be possible with v3?
>
Kristof
Chad La Joie
On Mon, Mar 5, 2012 at 08:22, Kristof Bajnok <baj...@niif.hu> wrote:
> Probably an RFE could help keeping track of this limitation, but I can
> agree with the Shib devs that your multiple IdP sessions + shared nameid
> + SLO scenario is quite special, and concerning the fundamental changes
> it seems to require, it will probably get low priority.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Kristof Bajnok
> On Mon, Mar 5, 2012 at 08:22, Kristof Bajnok <baj...@niif.hu> wrote:
>> > Probably an RFE could help keeping track of this limitation, but I can
>> > agree with the Shib devs that your multiple IdP sessions + shared nameid
>> > + SLO scenario is quite special, and concerning the fundamental changes
>> > it seems to require, it will probably get low priority.
>
> It won't get any priority since it's not according to spec.
You have made me curious. What part is against the spec? (The reason for
asking is admin logout, where you probably can't avoid the multi-session
problem.)
Kristof
Chad La Joie
SessionIndex that appears in the logout request message). When you
send a logout request you're requesting that that specific session be
destroyed. Destroying some other session, which will have a different
SessionIndex, would be improper.
That said, none of that really affects admin-initiated logout. In
such a situation you, the IdP admin, would just select the active
session you wanted to kill off and the IdP would end the appropriate
logout request to the applicable SPs. A UI *may* be able to detect
that sessions 1, 2, and 3 were held by the same principal and offer a
way to terminate them all at once but under the hood the IdP would
still perform 3 separate SLO flows.
> You have made me curious. What part is against the spec? (The reason for
> asking is admin logout, where you probably can't avoid the multi-session
> problem.)
>
> Kristof
> --
> To unsubscribe from this list send an email to users-un...@shibboleth.net
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Harald Strack
sorry for my late answer... but I became father... :-)
On Mon, 2012-03-05 at 14:22 +0100, Kristof Bajnok wrote:
>
> Probably an RFE could help keeping track of this limitation, but I can
> agree with the Shib devs that your multiple IdP sessions + shared
> nameid
> + SLO scenario is quite special, and concerning the fundamental
> changes
> it seems to require, it will probably get low priority.
I thought that I configured the SLO in a standard way! The multiple IDP
Sessions are very common in our environment as users have so many
devices (notebook, workstation, tablet, smartphone...). May there be a
way to use a dedicated NameID for every IDP-Session / Device of a user,
so that we end up in a 1:1 relation of NameIDs and Sessions?
br
harald
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Harald Strack, Dipl.Inf.(FH)
IT Development
ssystems
c/o todo GmbH
Alt-Moabit 60a
10555 Berlin
--
Cantor, Scott
>
>sorry for my late answer... but I became father... :-)
That's a good excuse.
>I thought that I configured the SLO in a standard way! The multiple IDP
>Sessions are very common in our environment as users have so many
>devices (notebook, workstation, tablet, smartphone...). May there be a
>way to use a dedicated NameID for every IDP-Session / Device of a user,
>so that we end up in a 1:1 relation of NameIDs and Sessions?
The IdP's transientID support has a bug that causes it to reuse transients
within the TTL of the transient mapping if the same SP makes a request of
the same user. One solution is to use the crypto plugins for transientID
handling, and that results in a guaranteed different NameID each time.
-- Scott