Background

At the 11th of October 2013 SURFnet contacted UNINETT(http://www.uninett.no) with the request to open source the SAML2 library, then a part of SimpleSAMLphp (SSP).

SURFnet has a SAML2 Single Sign On Proxy named OpenConext EngineBlock (EB) supporting advanced concepts such as license validation, consent, attribute enrichment, attribute release policies, advanced access management, runtime provisioning, advanced caching, 'virtual' identity providers, etc. In order to accomplish this it based it's proxy on a little known SAML2 Proxy library called Corto (created by WAYF). However this library had several disadvantages:

• No longer maintained
• Quirky architecture (array based) with little static guarantees
• Custom XML Encryption and Digital Signature implementation

UNINETT has SimleSAMLphp, an authentication middleware application with a strong focus in SAML2. Much of the functionality for SAML2 was encapsulated in a embedded library, purposefully designed to be released as a separate library at a future date. In fact lead developer Olav specifically wanted to release this library as part of a SimpleSAMLphp 2.0 release.

When SURFnet went looking for alternatives for Corto it quickly found SSP, though SSPs features did not match the features required of EB, it could use the embedded SAML2 library. SURFNet extracted the library to GitHub, removed all dependencies on SimpleSAMLphp, introduced Composer to SimpleSAMLphp (in a patch).

UNINETT was concerned over the current code as the library employed two styles of API and was not capable of handling the entire SAML2 spec. SURFnet had reservations about waiting for a 2.0 when it had an immediate need and wanted to release the library anyway, as a starting point for collaboration.

We could simply include SimpleSAML and use the classes we need, we're already doing this for some test cases, but if we're going to introduce this at the heart of the system I would like to make this API explicit, with it's own versioning. Also I will need to improve metadata generation, error handling, documentation and (unit) testing, I don't quite have the budget to do this for all of SSP, but I can do it for the SAML2 library.

SURFnet's OpenConext SAML proxy currently uses Corto for its SAML 2.0 stack. Corto is however no longer maintained so we would like to move to something which is maintained and more widely used. Since we would like to stick to PHP, simplesamlphp is a natural choice.

OpenConext has a different use however, so we would like to use only part of simplesamlphp, not the complete code. By factoring out the SAML code into a separate library, we can use just the parts we need, while simplesamlphp simple uses the SAML code as a dependency. Similar to the way OpenSAML is used by Shibboleth.

I think this would benefit both SSP and OpenConext, since code improvements in the SAML libraries need not be duplicated. Also, we could write unit tests for the SAML libs that will make that code easier to develop.

Lastly, we will probably have the code audited for security (and fix any problems if any would emerge), which should make good propaganda for SSP as well :-)

Boy's mail was mainly intended to see if you would support such an effort in principle, in the sense that there would be a fair chance that such code changes would be accepted in trunk. Otherwise, we would have to fork SSP, something which we'd rather not.