First I’ll describe the current architecture that is applied on today’s Service Provider Foodle https://foodl.org. Next, I’ll describe some modifications to the architecture that I foresee to happen soon.
The core component is SimpleSAMLphp running as a Service Provider. SimpleSAMLphp is kind of protocol independent, and has support for connecting to many of the commercial OpenID and OAuth based authentication systems available. Which protocol is used is transparent to the application, through the Authentication Source API. One authentication source typically has its own configuration, and is mapped to one authentication system, such as Google Auth or Twitter. All SAML IdPs is typically reached through a single Authentication Source that is given the IdP as a parameter (or uses the built in IdP Discovery Protocol).
Authentication sources are identified with a locally configured identifier, typically
google. These identifier are only used locally, and may be modified by the deployers.
- An embedded Discovery Popup that is used within the application UI.
As shown in the figure, we have deployed both configuration, a local (to SP) instance that runs a embedded popup discovery, and a central stand alone discovery service, that supports the IdP Discovery Protocol.
A very important aspect here is that multiple deployments of DiscoJuice may be configured to communicate. The protocol used between instances is the DiscoReadWrite protocol (not yet documented), which is backward compatible with the IdP Discovery Protocol, but adds a few new aspects:
- A generic authentication type parameter, that may be used in a closed environment to match the authentication source identifiers, and distinguish between
google and SAML authentication.
- The ability to send the selected provider, and not only request the answer. This is used for an embedded Discovery Service to be able to write a cookie in the domain of a central discovery service.
Installing DiscoJuice is super-simple. It can be as simple as just including a
DiscoJuice is fed with information about available providers in a simple JSON format called DiscoJuiceJSON. SimpleSAMLphp will have built-in support for offering a feed of UI-specific metadata in this compact format. For non-simplesamlphp deployments, DiscoJuiceJSON feeds can even be configured remotely (using JSONP). SimpleSAMLphp metadata aggregators also will have the ability to offer this format as well. The DisoJuiceJSON maps nicely to the MDUI Metadata Extension, and converting between the two should be trivial. If Kantara ULX comes up with a more appropriate JSON schema, I will be happy to replace DisoJuiceJSON in my implementations – harmonizing with other implementations.
Currently I have configured manual overrides of the Metadata to DiscoJuiceJSON conversion, because logos, keywords is missing in the source data, and I have added some for demo purposes.
The SAML Authentication Source gets metadata from the federation trough batch download of metadata documents.
A few simplifications that I foresee is:
- Batch download metadata does not scale, and will be replaced with MDX.
- Central offering of DiscoJuiceJSON instead of SAML metadata, because the discovery service will need a full list of available providers.
- SimpleSAMLphp may proxy and cache DiscoJuiceJSON, and also add locally configured alternative authentication mechanisms, such as
- SimpleSAMLphp may offer a single-entry Authentication Source, that nicely communicates with DiscoJuice. This will make configuration of DiscoJuice somewhat simpler for multi-protocol setups, and it may also feed the DiscoJuiceJSON proxy with JSON metadata according to the configuration.
Wants to know more?
I will release stable code, documentation and launch the architecture on TNC2011. Be there!