SLO processing rules

[Greg Whitehead <grw@trustgenix.com>]

On Jan 3, 2005, at 6:46 PM, Philpott, Robert wrote:

> ·         #0206: Clarify logout error handling [Owner: Greg Whitehead]

Better late than never... Ok, so shame on me for not looking into this 
sooner, but the good news is that I think there is a great 
simplification / improvement that we can make here.

The existing SLO processing rules have two problems:

	- The rules around the UnsupportedBinding status code, that are 
intended to make SPs retry with a front-channel binding if the IDP 
can't complete processing on the back-channel, are complicated to 
implement in the best case (even more so in SAML 2.0 than they were in 
Liberty since we have more Binding possibilities) and appear to 
actually be broken in certain proxying scenarios (see below).

	- The rules around handling individual failures discourage or even 
prevent an IDP from making a best effort to notify as many SP's in the 
session as possible, which seems contrary to the goal that we should 
have. If the user has indicated that they wish to terminate their 
session, or some compromise has been detected and the system is 
attempting to terminate their session, we should notify as many SPs as 
we can rather than abandoning processing or refusing to do anything at 
all.

The good news is that the fix seems to be easy:

	- Replace the complicated UnsupportedBinding retry processing rules 
with the simple rule that an SP SHOULD use a front-channel binding if 
it can. Thus, if an IDP receives a back-channel SLO request, it can 
take that as an inability (or unwillingness) of the SP to use the 
front-channel and it can go ahead and processes the request, skipping 
over any SPs in the session that don't support back-channel SLO. Note 
that an IDP implementation could differentiate itself by remembering 
those SPs and notifying them at some point in the future if the user 
agent associated with that session ever returns, but that wouldn't be 
required by the spec.

	- With the UnsupportedBinding error case eliminated, the processing 
rules around failures can be simplified to say that an IDP should make 
a best effort to notify all SPs in the session and then terminate the 
user's session at the IDP. It's probably useful to have status 
indication that indicates whether or not the IDP was successful in 
notifying all of the SPs, but either way the user's session at the IDP 
should be terminated. I would suggest that a top-level status code of 
Success indicates that the user's session at the IDP has been 
terminated and a sub-code could indicate that not all SPs were able to 
be contacted. Any error that prevents the user's session at the IDP 
from being terminated should return a top-level status other than 
Success.

For those who are curious, here are the various scenarios that SLO has 
to handle. The one that appears to be broken with the current 
UsupportedBinding processing rules is (4).


The simple cases without proxying.
	Assume SP1 and SP2 both in session via IDP


1) sp-initiated (no proxy)
	1a) SP1 -> IDP
	1b) 		IDP -> SP2

Note: In this first step (1a), we currently specify that the IDP should 
return UnsupportedBinding if SP1 uses the SOAP binding and SP2 doesn't 
support the SOAP binding. If SP1 can't retry with SOAP, in this case, 
the SLO is not done (and there is no way to cause the user's session at 
the IDP to be terminated). With the proposed rule, SP1 SHOULD use an 
HTTP binding if it can, in which case SP2 can be notified. If it uses 
SOAP, IDP will skip notifying SP2 and just terminate the user's session 
and return.


2) idp-initiated (no proxy)
	2a) IDP -> SP1
	2b) IDP -> SP2

Note: Here the IDP simply notifies both SPs.


The more complicated cases, with proxying.
	Assume SP1 and SP2 in session via IDP1 which has proxied to IDP2 and 
SP3 in session via IDP2 directly.


3) sp-initiated w/proxy #1
	3a) SP1 -> IDP1
	3b) 		IDP1 -> IDP2
	3c) 				IDP2 -> SP3
	3d) 		IDP1 -> SP1
	3e) 		IDP1 -> SP2

Note: Here, SP1 notifies IDP1 which was a proxy to IDP2. IDP1 in turn 
notifies IDP2. At this point, IDP2 notifies the SPs it has put into 
session directly and then returns to IDP1 which notifies the SPs it has 
put into session. With the current processing rules, if SP1 uses SOAP, 
IDP1 would first verify that SP1 and SP2 support SOAP and return 
UnsupportedBinding if not. It would then call IDP2, which would verify 
that SP3 supports SOAP, returning UnsupportedBinding if not. With the 
proposed rules, if SP1 uses SOAP, we just walk the tree and notify the 
SPs that we can, terminating the sessions at IDP1 and at IDP2 (assuming 
IDP2 supports SOAP SLO!).


4) sp-initiated w/proxy #2
	4a) SP3 -> IDP2
	4b) 		IDP2 -> IDP1
	4c)				IDP1 -> SP1
	4d)				IDP1 -> SP2

Note:  Here, SP3 notifies IDP2 which IDP1 proxied to for SP1 and SP2. 
In this case, if SP3 uses SOAP and either SP1 or SP2 don't support 
SOAP, the current UnsupportedBinding processing rules fall down, since 
we haven't allowed for IDP1 to return UnsupportedBinding to IDP2 (in 
resposne to an idp-initiated SLO). With the proposed processing rules, 
it's not a problem since SP3 will use a front-channel binding if it is 
able to. If it isn't able (or willing), SLO processing will simply do 
the best job that it can, skipping any SPs that can't be notified. In 
the end, it's much better to do what we can than to do nothing!


-Greg