If the logout action is initiated at the OP then asking the user for
scope is reasonable.
Scoping a logout coming from the RP is where it gets tricky.
Allowing a RP to initiate logout of the user at the OP and all of the
other RP is one of the use-cases that I have seen.
My C was making the assumption that this is SP/RP initiated making B
and C different.
understood.
SLO is more of an issue in the EU where some government's have it as a
requirement in there eGov deployment profiles for SAML.
our security team also requires SLO
In the US it is not in the FICAM SAML 2.0 deployment profile, for
several reasons.
I think the place to start is by creating a requirements doc so we can
all get on the same page for what the feature we want actually is.
agreed.
It is not enough just to say SLO is good.
That's true :-)
If you are coming to to the openID summit in London we can have a
session on SLO.
http://wiki.openid.net/2010-OpenID-Summit-EU
I'm unfortunately unable to attend, but I would very much like to
contribute to the WG's work.
regards,
Torsten.
If there are other hot topics people who are attending want on the
agenda let me know.
John B.
On 2010-05-24, at 6:50 AM, Torsten Lodderstedt wrote:
That is a reasonable approach and can be done within the existing
spec by best practices if OPs support checkID immediate.
the problem tends to be the scope of a logout button at the RP.
Why not ask the user for the scope of the logout action? a) seems
reasonable to me in any case. b/c could be triggered if the user
wants to be logged of from all RPs he/her logged into using the same
OP as the current RP.
BTW: would you really distinguish b and c? I would tend to offer a
user at most the option to log off from the whole "cloud" of the OP
and its RPs.
At Deutsche Telekom, we use a (proprietary) SSO/SLO protocol and
automatically logoff users from the OP and all connected serices when
they logoff from any service.
Should that:
a) only log the user out of the RP
b) The RP + the OP
c) The OP + all RP the user is logged into.
SAML has two methods for c using front channel using http
redirects. This is unreliable because users tend to close browsers
and this results in a unpredictable state. The other is to use a
back channel approach where the OP directly messages each RP that
the user has logged out. It works better but is more complicated.
The front channel approach has the advantage that the RP has access
to all of its cookies stored in the user agent. It can properly
cleanup the session and, moreover, this characteristics opens
opportunities to design a session management w/o the need for a
backend session database.
As you pointed out, the back channel approach is more complicated. It
requires a session handle and forces the RP to have a backend session
database, or at least a session revocation list.
A better approach would be for session cookies to be easily
identifiable in the browser and give the user a reasonable UI for
removing them.
That would be protocol independent.
If I understand you correctly, this requires some kind of browser
plugin aware of OpenId RP/OP session cookies. What troubles me is if
the user just deletes the cookies, the RP/OP does not have a chance
to detect the "logoff" and cleanup resources associated with the user
session.
regards,
Torsten.
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
