Shibboleth Developers

["Scott Cantor" <>]

> 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?

SAML/Liberty both present the profile as though the IdP has control over the
server. It's not even one server, it's a shared domain in which the IdP and
SP both have a presence on hosts of their own. That's directly implied by
the non-normative example of how the profile can work because it talks about
the IdP and SP "redirecting to itself in the shared domain".

> 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.

In SAML, the assumption is that the IdP is redirecting to itself in the
shared domain, so having metadata about itself isn't all that useful. Same
for the SP. And not everything has to be in metadata anyway, that's not
really the issue. Your point (I think) is that the IdP has to control the
endpoint or it won't know how to do the redirect unless it's part of a
single implementation. In other words, it's interoperable with certain
approaches, but not in others. That's fair.

> 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 SAML or Shibboleth? There is no need for the redirect to be specified any
further and still force implementations to support the profile, because the
redirect can be an internal matter. It works, as far as it goes. People have
implemented it (in Liberty anyway).

For Shibboleth, my initial response is, whatever applies to SAML alone
applies to Shibboleth anyway.

> 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).

It does something more than that, but we don't seem to see eye to eye on
this. It doesn't do a lot more because there's not a lot more that can be
done.

> 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.

Ok. I think we're on the same page here. I can't tell looking back that you
were trying to distinguish Shibboleth conformance from SAML's, since they're
intended to match.

> 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?

Sure, why not? SPs do because we tell them what it is. Now, do we need to
define more of a redirection protocol in the spec? Perhaps, I'm not sure.
But it wasn't clear to me that this was what your point was originally,
since you were asking "how can the IdP support this profile" and my answer
was "the same way Liberty or SAML IdPs do".

> 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.

Shibboleth should support any profile in this area that SAML has defined. We
can do more, but I'm not inclined to drop that profile unless somebody can
give me a good reason why we should. It's not like it's hard to implement.

And of course, SAML metadata isn't going to support a profile that's not in
SAML, and as I've argued, there is no metadata required to support the SAML
profile as it stands, so of course, there was none proposed.

It's not clear where the WAYF would fit into the metadata. It exists outside
the scope of anything that's been defined, except perhaps the
EntitiesDescriptor element, and that's a reach. It could be some kind of
distinct entity, I guess, but it amounts to a simple set of configuration
data (so far in fact it's nothing but a URL) that can be provided to a
deployment directly.

So my take is that in terms of conformance wrt the IdP, I'm not arguing for
anything other than what a SAML IdP already is expected to implement, and I
believe that this is sufficiently simple. That excludes a WAYF. With a WAYF,
the question I think is whether we need to sketch out a simple redirection
profile to get/set the cookie so that a WAYF and SP/IdP implemented
independently would interoperate. Maybe there's another small piece of spec
needed for that to work well and make life easier.

-- Scott