Shibboleth Developers

[Scott Cantor <>]

> There is a belief in the shib world that a single internet
> domain, e.g. example.edu, can contain within it multiple,
> independent targets, e.g., example.edu/team1/ and
> example.edu/team2/, toward which different attributes may be
> released.  This is a dangerous attitude.

I disagree. Not only with the fact that there's a consistent view of this on
the part of everyone involved with Shib, but that it's not possible for this
to work in at least some constrained way.

Personally, I fought the old app domain concept because of this problem,
among other reasons. I still feel in general that most host deployments
should identify themselves as a single SP when possible, and all the
internal details should be buried.

> Ultimately it is the browser that defines security boundaries,
> through its policies regarding cookie distribution and
> access to child page content - in particular its release
> of session cookies - and the browser considers the network domain
> to be the primary security boundary.  All paths within the
> same domain are considered to be, from the browser's perspective,
> the same application.  It will quite readily share cookies
> and page content among all applications on the same domain.

Not true, actually, cookies can and do get issued based on paths. Shibboleth
supports this, but of course that's not the real issue. If it's on the same
box, the assumptions about application separation are just that,
assumptions.

Shibboleth itself configured tightly provides, for example, *no* way for
resources behind any two distinct sessions to know about each other's
attributes unless they exchange data behind the scenes. Which they can. But
then they can do that between hosts too, so what is the problem we could
possibly solve?

> An origin may attempt to release the PersonPrincipalName
> for instance, to example.edu/team1/ but not to example.edu/team2/.
> All it's really doing is making it only slightly more difficult
> for team2 to get the user's principal name -- because the browser
> will not protect team1's session data from the team2 site.

Yes, this is true. But it's also the case that entangling origins with
knowledge of the details of how applications are hosted and trying to track
those changes in release policies has to be avoided at all costs in any
non-trivial cases.

So I think there are competing agendas. And I don't see any way of doing it
that solves the problem in any real way. Using DNS as a delimiter isn't a
solution, since the browser could have distinct sessions with two hostnames
that actually are the same server.

What matters is trust. If I release attributes to an SP, I trust him to
protect them. If I don't trust him, we have a deeper problem.

-- Scott