OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] handling of multiple SP logout


I will talk with the participant group on what method of "removing" the SP-B
actor works best for them. 

Thanks for the guidance on this situation.

Kyle Meadors
DGI
 
* * * * * * * * * * * * * * * * * * * * * * * *
CONFIDENTIALITY DISCLAIMER
This email, including attachments, is confidential and proprietary. It
constitutes exclusive communication solely to the addressee. Any entity
other than the intended addressee is prohibited from use of this
communication for any purpose. This email, including attachments, may not be
distributed, whole or in part.
* * * * * * * * * * * * * * * * * * * * * * * *

-----Original Message-----
From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com] 
Sent: Monday, August 03, 2009 3:55 PM
To: Thomas.Wisniewski@entrust.com; kyle@drummondgroup.com;
security-services@lists.oasis-open.org
Cc: cantor.2@osu.edu
Subject: RE: [security-services] handling of multiple SP logout

> Fair enough on the first point -- there's probably a bunch of errata
or
> minutes that led to the current decisions of whether to use
> Requester/Responder. 
[RSP] We'd have to jump in the WAYBACK machine for those notes... IIRC
it was back in the SAML 1.0 days (gosh I suddenly feel REALLY old!).

> The Liberty conformance tests are very light on negative
> (or error) tests related to msg processing. So these types of
decisions have
> no propagated to the tests yet.
> 
> As for disabling it, yes, physically removing the endpoint would work,
but
> this is a configuration update (basically it changes a partner's
original
> metadata).
[RSP] True. That could make dynamic on-line testing a bit more difficult
since there's more coordination involved.  Of course, you can just have
everyone provide the 2 sets of MD up front (one with and one w/o the SLO
endpoints). It is a bit more complicated, but should be workable.

> 
> I thought Kyle was leaning more toward a disablement where the
endpoint is
> somehow disabled outside of the acutal applications (i.e. no
application
> config changes out of the norm). I.e., perhaps a hostname update on
the
> tester/browser, so that a redirect to the SP being discussed cannot be
> completed. At least for this year's set of tests.
[RSP] I agree it would be preferable to not change MD.  If you are
strictly relying on an etc/hosts configuration, it might work.  However,
it might also be more error-prone depending on whether the failures
cause browser timeouts, etc. when using the recommended front-channel
bindings.

I think I'd still opt for the multiple configuration option. But perhaps
the latter could work...

> -----Original Message-----
> From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com]
> Sent: Monday, August 03, 2009 3:39 PM
> To: Thomas Wisniewski; kyle@drummondgroup.com;
security-services@lists.oasis-
> open.org
> Subject: RE: [security-services] handling of multiple SP logout
> 
> > Kyle, one addition to your point, I think that Requester (being
> returned from
> > the SP that the user logged out locally from), is more likely the
> response
> > code (as opposed to Responder). I.e., the requester is asking for a
> session at
> > the SP that no longer exists (as Scott mentioned, the SP does not
> maintain
> > this). So the LogoutRequest from the IDP is no different than one
> where a
> > bogus session index is used. I'm not sure why Responder would ever
be
> the
> > error case (if the SP doesn't understand the session index).
> 
> [RSP] I strongly disagree with using "Requester".  If the IdP keeps
track of
> the SP's to which it has provided an assertion for an SSO session,
then there
> is absolutely nothing wrong with the request.  The fact that an SP
might not
> maintain any state about the user session is a responder issue... not
a
> requester issue. BTW, some SP's do maintain state.
> 
> We've discussed this in the past...  IIRC the consensus was that a
SAML
> responder should normally only use the "Requester" error status in a
response
> if a SAML requester sent it a message that was ill-formed or was not
> conformant to SAML request generation rules.  If the message is
well-formed
> and otherwise "valid" w.r.t. SAML rules, but the responder cannot
satisfy the
> request, then this is a "Responder" error.
> 
> >
> > As for disabling the endoint, this is probably impossible since this
> is over a
> > redirect binding. The browser would just be stuck trying to contact
> the SPb
> > SLO endpoint.
> 
> [RSP] It's not impossible at all.  If SP-B has no endpoint, then the
IdP
> should never try to redirect there and there'd be no browser HTTP
request
> getting stuck.  That is, the IdP should skip that SP as it is going
down the
> list of SP's to which it needs to send a LogoutRequest.
> >
> > Tom.
> >
> > -----Original Message-----
> > From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com]
> > Sent: Monday, August 03, 2009 3:03 PM
> > To: kyle@drummondgroup.com; security-services@lists.oasis-open.org
> > Subject: RE: [security-services] handling of multiple SP logout
> >
> > > In the test group, we had a general agreement that if SP-B
returned
> an
> > error
> > > status, the IdP should send Success/PartialLogout to SP-A.
> >
> > [RSP] Yes... it's probably obvious, but for completeness you're
> missing one
> > additional requirement... if SP-B returns an error status to the IdP
> in a
> > LogoutResponse "AND the IdP successfully logs the user out of the
> IdP", then
> > that IdP must send Success+PartialLogout to the SP that originated
the
> > LogoutRequest.  The IdP could somehow fail to log the user out of
the
> IdP.  If
> > so, then it would return an error back to the original SP.
> >
> > >
> > > The area we chiefly need guidance on was the status returned when
> SP-B
> > > received a LogoutRequest from the IdP after it had already
> terminated
> > the
> > > session. It appears that either Responder or Success would be
> > permissible.
> > >
> > [RSP] IMO, yes.
> >
> > > The purpose of this test scenario was primarily to create a
> situation
> > so
> > > that the IdP did return a PartialLogout status to the originating
SP
> > and
> > > test out that functionality. Perhaps the best method to do that
> would
> > be to
> > > disable the SP-B endpoint so that the IdP is unable to contact it.
> >
> > [RSP] Yep - that's how I'd test it.
> >
> > >
> > > Kyle Meadors
> > > DGI
> > >
> > > * * * * * * * * * * * * * * * * * * * * * * * * CONFIDENTIALITY
> > > DISCLAIMER This email, including attachments, is confidential and
> > > proprietary. It constitutes exclusive communication solely to the
> > > addressee. Any
> > entity
> > > other than the intended addressee is prohibited from use of this
> > > communication for any purpose. This email, including attachments,
> may
> > not be
> > > distributed, whole or in part.
> > > * * * * * * * * * * * * * * * * * * * * * * * * -----Original
> > > Message-----
> > > From: Scott Cantor [mailto:cantor.2@osu.edu]
> > > Sent: Monday, August 03, 2009 1:12 PM
> > > To: robert.philpott@rsa.com; kyle@drummondgroup.com;
> > > security-services@lists.oasis-open.org
> > > Subject: RE: [security-services] handling of multiple SP logout
> > >
> > > robert.philpott@rsa.com wrote on 2009-08-03:
> > > > See below, but I think we could have an issue in defining the
> > "correct"
> > > > behavior here w.r.t passing or failing a conformance test...
> > >
> > > I don't think you can require anything here because the SP isn't
> > required to
> > > remember a session once it's locally terminated.
> > >
> > > > The spec isn't really precise on this use case. I personally
think
> > it's
> > > > best to pretend it worked and send "success" because of the spec
> > wording
> > > > related to #2 below...
> > >
> > > For the user experience, you absolutely SHOULD do that, but you
> can't
> > > require it.
> > >
> > > > To be more precise, the "IdP action" Scott is referring to is
> > whether
> > > > the IdP is able log out the user's session at the IdP.  It is
not
> > > > related to what happens at any of the SP's.
> > >
> > > Right.
> > >
> > > > Of course if the IdP receives an error from an SP due to item #1
> > above,
> > > > technically it has to report back a "PartialLogout" second-level
> > status
> > > > to the SP that originated the LogoutRequest.
> > >
> > > Right. That's all spelled out, is my point. Could be clearer, but
I
> > don't
> > > think "clear" and "logout" really belong in the same sentence.
> > >
> > > -- Scott
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC
that
> > > generates this mail.  Follow this link to all your TCs in OASIS
at:
> > >
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> generates
> > this mail.  Follow this link to all your TCs in OASIS at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]