Shibboleth Developers

[Scott Cantor <>]

>   Handle Service expected for Beta-1 should provide cookie-based SSO
>   across a replicated array of login sites, but still assumes
>   authentication is already done
> 
> This puzzles me.  I guess I can understand why some kinds of 
> local signon might benefit from having Shib do this, but it 
> makes me nervous to think that the SHS would be introducing 
> yet another cookie-based session, distinct from the local SSO 
> login session and any target-site session(s). Can you say 
> what you meant by this?

I don't know that the status of the code is, or whether it will be in
beta-1, but the design Walter was working on that I think you had
proposed as a nice solution to origin state mgmt was to encrypt the user
data into a handle and have the HS store that as a cookie.

With that design (with all the gaps filled in and polished up), you
effectively get SSO via the HS because it can recover the user's
identity from the cookie, just as the AA can recover it from the handle.

The replication comes from the fact that I would probably lean toward
using a load balancing approach that assigned all the HS sites the same
domain name and handled the load balancing behind the scenes, so a
simple per-site in-memory cookie should be able to sign me into any of
the replicated HS's.

Now, you don't have to set a cookie and create a session to use that
design, of course, but once you do, you can add the authentication code
to the HS, and the HS has become the Web-ISO authentication service.
There obviously isn't much point to doing that if you still have your
own SSO session going on. But, of course, I view running two separate
systems to solve the same problem as equally odd.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--