Shibboleth Developers

["Scott Cantor" <>]

> I posted this link previously:
> 
> https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/MyVo
csIdPDiscovery
> 
> At that time, you said you grasped it. ;-)

Sorry, I don't think I've seen that.

I understand the idea of proxying, I just don't see what filters have to do
with the cookie. There's not much code involved in reading a cookie
(request.getCookie()?), so I don't really understand what problem you're
trying to solve here with a filter or why that's better than a simple Java
class.

Also, in your diagram, I don't see any place where a CDC is being used in
the intended way. All the cookie traffic appears to be local to the proxy.
If you have a proxy, by definition there's really no common domain in the
SAML sense. There's no reason to bother with any of this stuff, you have
control of the user so you can cache a cookie any way you like, just like
the WAYF does now. Doesn't matter what it's called or what the format is, we
all just sort of gravitate to the SAML cookie for want of any reason to do
something different.

If you're really saying there's a true SP and IdP in the myVocs box, then
FWIW, the cookie's already being written for you by my code on every login.
All you have to do is add code to your WAYF to read it in the way in, which
the current WAYF code does.

Maybe I'm missing the point here, but that's what it looks like to me. I
don't see a role for the CDC in there.

-- Scott