SOAP SLO handler: what would it be used for?

[Eric Goodman]

As I understood it:

With SAML1 artifact resolution, the attributes "query" is always preceded by an authentication event.

With SAML2 attribute queries, I thought the IdP could be used as an non-authenticating attribute authority (i.e., in a circumstance where there was no preceding authentication event). Is that not true? I understand avoiding redundant queries is a good thing, but in the latter use case, it's not redundant. I think Keith's point about ECP is valid, but I thought ECP still presumed a preceding authentication event.

I'm calling it out since it's another place where disabling attribute queries would affect functionality (though perhaps an advanced and uncommon one). And I guess there's a difference between disabling attribute queries and listing the endpoint in the InCommon metadata...

--- Eric

> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Wessel, Keith
> Sent: Wednesday, April 16, 2014 11:40 AM
> To: Shib Users
> Subject: RE: SOAP SLO handler: what would it be used for?
> 
> Thanks, Tom and Scott. Looks like we can get rid of five, not just
> four, endpoints.
> 
> BTW, Tom, your page looks like good advice. Might want to further
> quantify your statement about not supporting SOAP endpoints, though, by
> making ECP the exception. I'm sure the researchers on this list would
> want to encourage any new IDP to support ECP out of the gate.
> 
> Keith
> 
> 
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-
> bounces at shibboleth.net] On Behalf Of Tom Scavo
> Sent: Wednesday, April 16, 2014 12:48 PM
> To: Shib Users
> Subject: Re: SOAP SLO handler: what would it be used for?
> 
> On Wed, Apr 16, 2014 at 1:07 PM, Wessel, Keith <kwessel at illinois.edu>
> wrote:
> >
> > We’ve decided, since nobody’s using it, to get rid of back-channel
> > handler support on our IDP.
> 
> That's good news. Your metadata (and your configuration) will be
> greatly simplified.
> 
> > I encourage others to consider this route.
> 
> Indeed. For new IdPs, it's mostly a no-brainer. Here are some
> preliminary thoughts on this issue:
> 
> https://spaces.internet2.edu/x/4YHYAg
> 
> Those recommendations have not yet been vetted, however, so take them
> with a grain of salt. If anyone has comments or suggestions, I'd like
> to hear them.
> 
> > I’m planning to remove the SAML1 and 2 attribute query and artifact
> > resolution endpoints from published metadata, local metadata, and
> > handler.xml.
> >
> > Looks like /idp/profile/SAML2/SOAP/SLO also uses back channel
> > communications… and we can turn that off, too. I’m just curious,
> > though, what would be a use case for a SOAP SLO call?
> > Non-interactively terminating a user’s session?
> 
> An inbound SOAP-based SLO endpoint doesn't seem to be very useful.
> However, outbound SOAP-based SLO is what's being implemented in v3, if
> I recall. If that's right, this means SPs will expose a SOAP endpoint
> for this purpose.
> 
> > I assume that the SOAP SLO call uses a similar security model to
> > artifact resolution and attribute queries and thus should be turned
> > off if we’re turning off the others. Is that correct?
> 
> AFAICT, yes.
> 
> > And finally, does ECP not use this security model? Looks like we have
> > that running on 443, so I assume it’s not using a cert from metadata.
> > Is that right?
> 
> Someone else needs to answer definitively, but yes, I think you're
> right, ECP is the exception.
> 
> Tom
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net