Skip to content

Background

Jump to bottom
Pieter van der Meulen edited this page Nov 12, 2013 · 3 revisions

Introduction

At the 11th of October 2013 SURFnet contacted UNINETT on the SSP list with the request to make SAML2 library code that is part of SimpleSAMLphp (SSP) a separate library that can be used independently of SSP.

What followed was a private discussion between UNINETT and SURFnet resulting in a decision to go forward with this effort. In the process many aspects of creating such a library were discussed. Below is a summary of this discussion providing some background.

For readability the content was organised by subject. I took the liberty to change some obvious misspellings. My comments are between []'s. Any errors, omissions and misrepresentations are of course mine [PM]

Participants:

  • BB - Boy Baukema (SURFnet / iBuildings)
  • JP - Jaime Pérez (UNINETT)
  • JD - Joost van Dijk (SURFnet)
  • OM - Olav Morken (UNINETT)
  • PM - Pieter van der Meulen (SURFnet)

Topics

These topics have their own page:

Background

SURFnet has a SAML2 Single Sign On Proxy named OpenConext EngineBlock (EB) that includes much more functionality than "just" being a SAML proxy. It includes support for consent, attribute enrichment, attribute release policies, access control based on group membership, just in time provisioning, 'virtual' identity providers, etc. The SAML proxy is based on a little known SAML2 Proxy library called Corto (created by WAYF). Corto is however no longer maintained so SURFnet would like to move to something which is maintained and more widely used. Sticking to PHP, SSP is a natural choice.

OpenConext has a different use however than SSP, so SURFnet would like to use only part of SSP, not the complete code. SURFnet proposes to factoring out the SAML code into a separate library, usable by OpenConext, while SSP uses the SAML library as a dependency. Similar to the way OpenSAML is used by Shibboleth.

SURFnet offers to do the work of creating a separate library based on the current SSP and changing SSP to use this library, but highly prefers to do this in a way that the work is accepted in trunk. When such a library exists SURFnet could contribute unit tests, as we would need these for OpenConext. SURFnet will probably have the library audited for security (and fix any problems if any would emerge). This would be a benefit to SSP.

Response from UNINETT

JP:

Regarding your proposal. Short answer: definitely yes. Long answer follows:

We've been discussing long time about SSP 2.0 here. Olav has a "masterplan", which pretty much aligns with your view. Basically the idea is to detach the SAML library, so that's easier to develop and use by third party products, and then have separate modules on top of it that implement the actual functionality of an IdP or an SP, for example. This would be much more flexible for users to use, and even to install and configure. For instance: go fetch the SSP + SP + webadmin, drop it on your web server, configure a few things, and you are done.

To summarize: I think we should definitely start talking on SSP 2.0 and how to get this done, as looks like we have common goals. Our main problem right now is the lack of muscle to do the work, as our idea is to do a major rewrite of the library, not just some refactoring.

Clone this wiki locally