Shibboleth Developers

[Scott Cantor <>]

> So here is the new flow we propose (please forgive my mixed vernacular 
> of old and new Shib terms that will follow).

Feel free to not use any Shib terms at all, I'm desperately trying to stop
using them. ;-)

A Shib HS is a SAML authentication authority. A SHIRE is a SAML assertion
consumer service and if that web location happens to be overloaded with
more, it's just serving as a protocol endpoint for multiple protocols
(logout, for example).

> User comes from a resource 
> to the Handle Service, either via WAYF or a direct link, and they 
> authenticate in some fashion, end up with a handle, and get sent back to 
> the resource.  So, same model as exist now.  The only difference here is 
> what the handle service stores, instead of just making a handle to user 
> mapping that the AA will user later it stores a handle/user/resource 
> mapping.

In SAML 2.0, each SSO assertion's statement contains a SessionIndex, and the
index is used to trigger logout later. It supports a single user having
multiple sessions with an SP via different devices (say a browser and a
phone). That way you get per-session logout support.

> Once the user gets to the resource the thing formally know as the SHIRE 
> takes the handle and does its thing.  At this point an out of band call 
> could be made back to the Handle Service to verify that the handle is 
> indeed valid (which could mean something like checking to make sure an 
> expiration timeout hasn't passed).  This might add just a bit more 
> assurance to this exchange though it may not be necessary.

It's not, IMHO, as handles are not security tokens, but rather simply just a
name. You could also check if a Kerberos principal name was still valid, but
you probably wouldn't.

In our current stuff, there's no real notion of an IdP session, but with
2.0, we can signal the length of this session using the SessionNotOnOrAfter
attribute. That would eliminate the need for any extra callbacks.

> At this point the Handle Service would send to each SHIRE a "log handle 
> X out" message.  To do this it would need to resolve the resource id to 
> a SHIRE URL which could be done in a whole lot of ways, both dynamic and 
> static.

SAML metadata supports advertising the endpoints you use at an SP or IdP for
SingleLogout messages.

> Now I can see some app provider saying "I don't want you to put no 
> stinkin graphic on my site, you'll mess up my look and feel" because 
> I've heard it here at VT.  This is a very valid point so a single pixel 
> transparent gif can be served up for them (and you thought web bugs were 
> just for spam and slimey marketing stuff).

I think it's probably risky because many browsers easily can block this,
which renders the mechanism hard to rely on.

> Just a short comment about naming.  In this model it MAY be a good idea 
> to call the thing on the Origin side that handles session stuff 
> something other then the Handle Service and it MAY be a good idea to 
> call the thing on the resource side that handles session stuff something 
> other then whatever the SHIRE is now called.

I think it would be great to never use the names again, I just wish we
could. ;-)

Thanks for the detailed suggestions. Have you guys dealt with the way this
functionality is exposed to applications? Do they register somehow for
logout notification? I was at least tossing around ideas for adding
configuration elements so that the Shib applications can expose endpoints
for notifying them that logout is happening.

Similarly, I suppose something like that would work on the back end for
notifying the authentication layer.

-- Scott