Shibboleth

Shibalike: a PHP emulation of a Shibboleth environment

 

Update 2011-06-23: All the essential components of Shibalike are complete and the project is hosted on Github. This is currently blueprint-ware, but I’m excited about it.

A co-worker and I have laid out a design for a flexible system that can emulate a working Apache/PHP Shibboleth stack, without requiring any outside resources (e.g. an IdP, mod_shib, shibd). I see this as useful in several cases/for several reasons:

  • Setting up your own IdP for testing would be a pain and a maintenance headache.
  • Depending on your institution, getting attributes approved for release to a new host may be time-consuming or impossible.
  • Shibboleth won’t work on http://localhost/.
  • You want to be able to test/experience a similar sign in process on localhost as users do in production.
  • You want to be able to test your PHP-based shibboleth auth module without a working shib environment.
  • You want to emulate an IdP problem, or allow a secondary auth method to kick in if the IdP is down (without switching auth adapters).
  • You might want to “hardcode” an identity for a unit/integration test
  • You might want to give a select group the ability to login under a testing identity after they authenticate at the real IdP.

Continue reading  

Bookmarklet and PHP to prevent Shibboleth-related Firefox Lockouts

 

Reason this might be useful.

/*
 * Remove all _shibstate cookies if there are too many of them. This usually
 * occurs due to Firefox session restores. Unfortunately we don't know which is
 * the active state cookie, so we have to delete them all, but this is a lessor
 * crime than locking the user out with server errors.
 *
 * In an app a good time to call this is when a user is not logged in or has an
 * expired app session. This way we can cleanup their cookies before forwarding
 * them to the shib login process. Also after logout you'll want to call this
 * with parameter 0 to always remove them.
 *
 * @param int $allowableStateCookies if the number of _shibstate cookies
 * exceeds this, they will all be removed.
 */
function Shibboleth_preventFirefoxLockout($allowableStateCookies = 10)
{
    $stateKeys = array();
    foreach ($_COOKIE as $key => $val) {
        if (0 === strpos($key, '_shibstate')) {
            $stateKeys[] = $key;
        }
    }
    if (count($stateKeys) > $allowableStateCookies) {
        foreach ($stateKeys as $key) {
            setcookie($key, '', time() - 3600, '/');
        }
    }
}

Here’s a bookmarklet that essentially does the same thing: Fix Shibboleth Lockout

Uh-Oh: Firefox’s Unique Session Cookie Behavior

 

By now, Opera’s invention of restoring tabs automatically is available in most browsers, but unlike every other browser, Firefox’s restored tabs retain session cookies for the domains of the saved tabs Firefox restores all session cookies as if the browser were never closed. This is handy in some ways, but dangerous in others:

It’s fooling web developers by breaking a very old and widely-known convention. Since Netscape’s original spec (around 1994) a cookie with an empty/missing expires was to be discarded “when the user’s session ends” (later clarified as “when the user agent exits” in RFC2109), and thousands of prominent web pages describe “session cookies” this way.

A common session design pattern uses a persistent cookie to establish low-level identity info and a session cookie for full authentication. Developers may not know that their full auth period may be lasting days or weeks, including trips to insecure wifi spots, browsing by multiple users, etc.

It’s fooling users. No one thinks of a single browsing “session” as encompassing several days of browser usage just because the same tabs were open, and users frequently read that they need to simply exit their browser to ensure their session is ended.

Recommendations

  • Be aware that Firefox session cookies can linger for days, despite the user having closed their browser.
  • Manage session timeouts on the server-side and/or via HMAC-signed timestamp values in the cookie contents (don’t let the client decide how long a session should last).
  • If you can, include secure in the cookie header. Firefox does not restore HTTPS session cookies. Realize that in later FF versions, “secure” cookies also are restored.
  • If you give out session cookies with unique names, have your application clean these up when they’re no longer needed. If you don’t, your Firefox users could suffer from…

Cookie Accumulation Torment

This annoying situation occurs when Firefox gains so many local cookies that the web server begins to deny all your requests. Deleting some or all these cookies is the only way to fix the issue because—yay—the problem session cookies persist across browser, and even OS, restarts.

Big Shibboleth Implications

If your Shibboleth-authenticating app maintains its own session, make sure that the “sign out” function searches for and deletes the local Shibboleth cookies (or that the SP sets only “secure” cookies). Otherwise this could happen:

  1. Jane “signs out”, closes Firefox, and lends her computer to Sally.
  2. Sally opens Firefox and clicks “sign in”.
  3. Sally is instantly authenticated into Jane’s account!

Jane’s application session was over, but Firefox allowed her Shibboleth session to live on.

Also, since Shibboleth gives out uniquely-named session cookies (prepended with _shibstate), failing to clean these up will lead Firefox users to the aforementioned torment. If the user has an app open all day every day, count on her gaining at least one cookie per day.