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


> 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]