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.

Basically Shibalike will inject some attributes into $_SERVER (possibly overriding what mod_shib put there) before your app’s shibboleth auth adapter runs. You just have to provide the attributes/values that your shibboleth auth adapter requires.

How’s it gonna work

The model we came up with is pretty simple, and is analogous to how shibboleth works:

• User: a simple value object with a username and array of attributes
• StateManager (interface): must store a User associated with the current browser (e.g. using $_SESSION). This is like shibd‘s cache.
• AttrProvider (interface): must provide attributes by username (e.g. from a DB). This is like your IdP’s identity database.
• IdP: allows marking a user as authenticated, or logging out the current user
• SP: provides PHP with attributes for $_SERVER, and can redirect to your “login app”

Before your auth adapter, you call SP->getUser() to fetch some attributes to put in $_SERVER. SP asks your concrete StateManager for the User, and if not found, it redirects to your login app.

Your login app first authenticates the user using any method (e.g. any Zend_Auth adapter), then calls IdP->markAuthenticated($username). IdP asks your concrete AttrProvider for the new user’s attributes, creates a User object, and stores it in StateManager. It then redirects the browser back to the previous URL.

Flexibility

With StateManager and AttrProvider defined as interfaces, you can easily make concrete implementations determining exactly where you want attributes to come from, where the User object is stored and how it’s tied to the browser. Your login app can use any crazy logic it wants to to authenticate users and to pass them into the system.

Umm…coming soon!