16 2011

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.

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!

2 Comments on “Shibalike: a PHP emulation of a Shibboleth environment”

  1. Hi Steve,

    I actually saw this before you posted it on the UF Shibboleth list, but hadn’t gotten a chance to read it yet. It sounds like you’re automating most of the work folks have to do manually when testing their PHP apps that use Shibboleth. That’s pretty handy, so thanks for doing this :)

    A couple of my thoughts & questions:

    – You say, “Shibboleth won’t work on http://localhost/.” While it probably isn’t a great thing to do, I’m not sure there’s an actual limitation on using localhost. The only thing interpreting URLs between the SP and IdP is a user’s browser, which should deal fine with localhost (and we have some folks who have “localhost” in their metadata).

    – Have you considered integrating your ideas into a PHP object mocking framework? Or a unit testing one that includes mock functionality?

    – There are some ‘weird’ cases that your framework could be very useful for testing against. Some that I think would be neat:

    1. having $_SERVER data removed out from under your application

    2. a different user’s data being populated into $_SERVER during a session

    3. having an SP session timeout create a redirect to the IdP during the user’s workflow (interrupting it), or bookmarking of protected pages

    4. expiring sessions from your StateManager and making your application behave correctly

    5. Testing forced reauthentication and ShibAuthInstant

    Anyway, you should post this to the public Shib users list (http://shibboleth.internet2.edu/lists.html) and see what folks think about it. I’d bet you’ll get a very positive response.

    Cheers,

    Martin

  2. SimpleSAMLphp has PHP implementations of SAML2.0 IdP and SP, and already has a bunch of auth adapters for the IdP. So that might be a partial solution to the sp-on-localhost problem. (whether or not running an SP on localhost is technically possible, I’d much prefer a drop-in-place PHP implementation).

    Re: testing, mocking any piece should be easy, and I imagine we’ll include PHPUnit tests, but I don’t know what a testing framework would gain by adding Shibalike to their distro, if that’s what you mean.

    All those weird cases should definitely be emulate-able.

    What is ShibAuthInstant? Google didn’t help.

    I’ll post to the public Shib list when there’s some code. I see the biggest value of this in that it should make writing/debugging auth plugins easier (to get better support for shib in apps).

Leave a Reply

Elements allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>