service provider php guard implementation

Fri, Apr 7, 2006

Having just finished a load of changes to the distributed SP, I thought I’d make it live up to it’s distributed nature by implementing a PHP Guard. It’s early days yet but the Engine now has a REST interface that works in the same way as the JAX-RPC interface. The PHP Guard first contacts the Engine to get the WAYF location, redirects to the WAYF and from then on, the Engine takes over, processing the SAML and finally forwarding the attributes to the PHP Guard.

The shibbing of the PHP pages is handled by auto_prepend_file in a .htaccess file. What auto_prepend_file points to is the PHP Guard implementation, which takes a note of the real page you’re after, contacts the Engine, redirects you to the WAYF and processes the session once the attributes arrive. It then forwards you to your original page, which then has access to the attributes from the IdP.

The question at the moment is whether to give REST version Guards non SOAP packets containing the attributes as SOAP functionalty isn’t installed on most servers. It would be easier to write a minimal GDK (Guanxi Development Kit) that will define attribute formats for REST version Guards to parse easily. The JAX-RPC Guards get their attributes in a SOAP message. The components are the same on the PHP side. There’s a main Guard (guard.php), an attribute consumer script (acs.php) and an attribute podder script (podder.php), all of which the Engine contacts in the workflow.

When attributes arrive, acs.php sets up a marker to let guard.php know to let the original request through, while podder.php makes the attributes available to the original page and any other pages below it.

So that’s a central Java Engine with a clutch of Java JAX-RPC Guards looking after Tomcat hosted resources and a PHP REST Guard looking after Apache or IIS (theoretically) hosted resources.

comments powered by Disqus