Shibboleth Developers

[Jim Fox <>]

The path part of cookie's scope is provided only as a convenience
for cooperating applications.  It provides no security whatsoever.
It is trivially easy for an application to read any cookies
'scoped' to other applications in the same domain.  The browser
provides security isolation between domains, but nothing past that.

Jim



On Sat, 18 Dec 2004, Howard Gilbert wrote:
> > Why can't the cookie be scoped to the entire server (path=/)?
>
> I can write the UUID in an explicit Cookie scoped to the entire server
> qualified by its association with "shibboleth" and by the applicationId.
> This has two downsides. First, the cookie has to be explicit, not implied as
> would be true if the data is really a property in the HttpSession object and
> we let the Application Server generate its internal Cookie to ID the
> HttpSession. That's really no big deal. The other problem is that any RM on
> the server can get the attributes associated with any applicationId on the
> server because now the UUID is no longer local to specific contexts.
>
> I believe that Scott would point out there is no real hard security between
> Tomcat contexts, that RMs on the same server have to be well behaved, that
> an administrator should not expect real separation, and therefore there is
> no reason not to scope the UUID cookie to the entire server. Scott believes
> that the only meaningful unit of integrity is the SP, and any separations
> within the SP are based on good behavior.
>
> Such pessimism is realistic in view of the recent history of security
> problems in servers and operating systems. However, all that trash is
> written in C, with its buffer overruns and unchecked operations. Thirty
> years ago mainframe systems ran applications where thousands of users
> interacted with an Application Server (CICS) that maintained data security
> between uses simply by careful programming. Tomorrow, both Java and CLI
> should be able to enforce data security across contexts or appdomains
> automatically. So I am reluctant to design pessimism into a system as a
> permanent restriction just because it would not be responsible today to
> assume that security can be enforced.