Skip to Content.
Sympa Menu

shibboleth-dev - RE: Multiple targets in a single domain?

Subject: Shibboleth Developers

List archive

RE: Multiple targets in a single domain?


Chronological Thread 
  • From: Scott Cantor <>
  • To: "'Diego R. Lopez'" <>,
  • Subject: RE: Multiple targets in a single domain?
  • Date: Thu, 01 Jul 2004 08:56:49 -0600
  • Organization: The Ohio State University

> That's why PAPI uses a symmetric key for encrypting all session
> cookies. Each target has its own key so even in the case the browser
> discloses cookies to targets in the same domain name, it remains opaque
> to the others. I think that implementing this inside the Shib target
> would not be difficult at all.

There's nothing in our cookies, they're session keys. Furthermore, two
applications running on the same host most likely have access to each others
keys. If they don't, that's making an assumption about the deployment
environment (for starters, none of the logic could run inside the web server
since it would run as a single user account). I think what you're describing
works (sometimes) in a case where the logic that uses the key runs as a
library called by the application, and runs as the application's ID. That's
not all that commonly helpful since most modern web app environments don't
run apps as distinct processes with distinct identities.

However, I'd like to clarify something...I didn't think the attack Jim was
concerned about involved one application obtaining another application's
session key for a user, except in the case where it would then impersonate
the user (which would require IP spoofing or disabling the IP check).

If the concern was just about the evil app using the session key for some
purpose, that's easily prevented, since we don't offer any direct API to use
the key for anything. We associate session keys with the applicationId in
the config file, and any request to the evil app doesn't get associated with
anything but *his* applicationId. If he tries to use the session key from
the other application (such as setting the value back in his own session
cookie), it won't work. Or if it does, it's a bug we can easily fix.

OTOH, if you have enough access to the web server or SHAR process or session
cache database to change the configuration, or use the session key to do
something, well, you don't need the session key. You've already got all the
data you want to steal.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page