Shibboleth Developers

[Tom Scavo <>]

Okay, you corrected me on a number of points and I relent in all cases
except one:  the IdP does not set the cookie.  It can not, since then
the cookie would not be visible to any host outside the IdP's domain. 
Therefore the IdP must redirect to the common domain cookie writing
service, and therein lies the rub...the IdP has no hand in the profile
except to redirect to the common domain server (which is generally
outside its control).  The details of this redirect are out of scope,
so I'm back to my original question: how does the IdP "support" the
profile?

I'll try to answer my own (nagging) question. ;-)  If the common
domain service endpoints were in metadata (like all other
browser-facing endpoints), the IdP could support the profile by doing
a metadata lookup and redirecting to the common domain if the
appropriate metadata element existed.  However, AFAIK there is no such
metadata element defined in SAML, and moreover, the details of the
redirect URL are not specified by the profile.  Therefore, it does not
seem reasonable that the IdP MUST support the IdP Discovery profile. 
In my opinion, the profile is too vague to be really useful.  All it
does is define a standard for a client-side cookie (well, mostly).

Now if the IdP managed its own instance of the common domain server
(which seems to be the intent of the profile in Liberty and SAML),
then perhaps we might have a different story, but the profile does not
require this.  Moreover, the intent here (upon reading the new version
of the Shib profile spec) is to roll the functionality of the profile
into the WAYF service.  Do Shibboleth IdPs know the whereabouts of a
WAYF service?

Yes, I have a problem with IdP Discovery in SAML2 because it's too
vague (as I've argued above).  I have a more difficult problem with
IdP Discovery in the case of Shibboleth since the latter already has a
discovery mechanism.  I believe the two should be combined (more
precisely, IdP Discovery should be subsumed by the WAYF) and
Shibboleth metadata should support it.  Better yet, SAML metadata
should support it.

Okay, I think I've beat this horse dead enough.  I hope I've made some
sense of this issue.  I hope I'm not too far off base.

Cheers,
Tom


On Wed, 10 Nov 2004 20:17:21 -0500, Scott Cantor 
<>
 wrote:
> I think I see the problem...
> 
> > The profile specifies that the common domain cookie writing service is
> > invoked after the principal is authenticated by the local authn
> > service.
> 
> That's not what my copy says, but I don't recall if the text has changed
> since CD2. Maybe that's the confusion. Somebody (I thought it was you)
> commented on some aspect of this text, but anyway, what it says now is:
> 
> "After the identity provider authenticates a principal, it MAY set the
> common domain cookie."
> 
> Nothing in there about "local authn service". The boundary between the IdP
> and "local authn" is what's really out of scope. The entire box around the
> SAML behavior and authentication is what really makes up the IdP.
> 
> > Now the authn event is out of scope and as far as I can tell
> > the invocation of the cookie writing service is out of scope as well.
> > That doesn't leave much for the IdP to "support", I'm afraid!
> 
> That's not my reading, and it's definitely not the actual fact. The IdP sets
> the cookie after authentication and before responding to the SP. It's
> certainly not done by the "local authn service" since it can't. That entity,
> if it even exists, is legacy code that isn't SAML aware.
> 
> In practice, of course, SAML products other than Shibboleth all do the
> authentication themselves because, well, it's easier to control logout that
> way.
> 
> > Given what I know about typical authn services, I could imagine that
> > the IdP might redirect to the local authn service with a parameter
> > that targets the cookie writing service, something like this:
> >
> >   https://idp.com/auth/controller?action=login&target=target
> 
> No, how would it have any hope of the local service supporting this profile?
> Not realistic, I don't think.
> 
> > So after the authn event occurs, the cookie is updated, and the client
> > ends up back at the SSO service so that the message flow can continue.
> 
> More like:
> 
> SP sends request
> IdP either authenticates by itself or protects its endpoint with some other
> authn service
> IdP sets cookie
> IdP responds to SP
> 
> -- Scott
> 
>