Per-Entity Metadata Working Group

["Domingues, Michael D" <>]

In the spirit of discussion, I figured that I’d elaborate a bit on what I meant when I mentioned that I've seen cloud-hosted SPs having difficulties consuming the InCommon metadata aggregate. It occurred to me shortly after our call that there are at least two cases in which this is problematic. The first case is merely an indication of the unsustainable current state of metadata distribution, while the other, I believe, we’ll want to take into account in order to ensure that the per-entity metadata service we define will be accessible to as many current (as well as future) federation participants as possible.

 

Case One -- Cloud Instances of Traditional Service Provider Software:

This is the case I was thinking of last week. Our campus web developers are currently in the midst of migrating our CMS to a cloud-hosting platform. We had planned on adding their SimpleSAMLphp service providers to the InCommon aggregate, but our web team couldn't get the automated metadata refresh module to consume the InCommon aggregate within the PHP memory_limit their vendor had specified. (The vendor drew a hard line at 194MB.) For the time being, we've had to resort to bilateral federation with their deployment.

 

Cases such as this (memory constraints on cloud-hosted instances of traditional SP software) will be resolved by the deployment of a MDQ service.

Case Two -- Cloud Instances of Proprietary or Home-Assembled Service Provider Software:

For the most part, participants in our respective federations use some combination of the "major-player" SAML implementations, which have been listed on the MDQ Client Software wiki page [1]. However, as an IdP-operator, I've noticed that a handful of the (bilateral, non-InCommon) cloud-hosted services our campus has licensed recently use either proprietary or home-grown/home-assembled SAML software. More often than not in these cases, it's been something pieced together from the OneLogin suite [2] -- the GitHub appliance uses OneLogin internally for example -- though I'm sure there are other projects out there.

One could (justifiably) argue that these "build-your-own Service Provider" deployments have poor to nonexistent automated metadata consumption capabilities in the first place. That being said, I think our current work provides us with a window of opportunity to get these projects on the MDQ (let alone non-bilateral metadata exchange) bandwagon.

Do others see value in attempting to reach out to these projects, or have other cases like this in mind? I remember that trying to loop (Ping|Okta|Microsoft) into our discussions was brought up last time (with doubts cast upon the potential success rate of doing so), but I still believe that it behooves us to at least make the effort.

Michael

[1] https://spaces.internet2.edu/display/perentity/MDQ+Client+Software

[2] https://github.com/onelogin/