Per-Entity Metadata Working Group

[Tom Scavo <>]

On Wed, Jul 20, 2016 at 2:45 PM, Nick Roy 
<>
 wrote:
>
> Re: engaging with {Microsoft, Ping, Okta} - Scott's right, I think the 
> engagement with at least Microsoft and Ping re: the SAML v2.0 
> Implementation Profile for Federation Interoperabililty has born some 
> success, and that profile requires MDQ support.  Per-entity metadata 
> support seems to be much more easily achievable for solutions like 
> Microsoft ADFS and Ping Federate, because by definition they are able to 
> deal with entity descriptors in isolation, instead of wrapped in an 
> entitiesdescriptor.  If this group could identify some points of pressure 
> worth exerting, I'd be more than happy to start working on the 
> relationships (in cases like Microsoft and Ping, they are already in place).

I don't disagree with any of that but it seems we should start by
documenting what Microsoft and Ping are capable of doing TODAY. That
is what the MDQ Client Software wiki page is for:
https://spaces.internet2.edu/x/SIL4BQ

Ping is not on that page. MS AD FS is on that page but its per-entity
capabilities are not documented because no one here seems to know for
sure.

I'm guessing AD FS does not support the MDQ protocol per se but it
will let you configure a URL to a single entity descriptor. The
security model is probably TLS but I don't know if AD FS supports
explicit anchors. I'll go way out on a limb and guess that Ping is
similar.

But these are just guesses...who knows for sure?

Tom

> On 7/20/16, 6:52 AM, 
> "
>  on behalf of Scott Koranda" 
> <
>  on behalf of 
> >
>  wrote:
>
>     Hi Michael,
>
>     Thanks for this thoughtful note.
>
>     Comments and questions inline below.
>
>     > 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.
>
>     Interesting.
>
>     Is there an opportunity for the service providers to consume
>     metadata from the InCommon pilot MDQ service that Tom Scavo
>     will talk about?
>
>     Of course there is no service guarantee for that pilot (as I
>     am sure Tom will explain), but maybe a dev/test tier of the
>     SP(s) might be appropriate for such an exercise?
>
>     I think identifying both SPs and IdPs that can tolerate more
>     risk and help InCommon explore per-entity metadata in
>     practical ways can be useful and a product of this working
>     group.
>
>     > 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.
>
>     Yes, I see value in attemtping to reach out to those projects.
>
>     It will likely be one of those efforts that shows little
>     immediate payoff but could set the stage for later useful
>     work.
>
>     Questions:
>
>     - Is this the right group to begin the outreach? Or should
>       this group "tee it up" for another group?
>
>     - Are there other outreach efforts (say around the new SAML
>       V2.0 Implemenation Profile for Federation Interoperability
>       at
>       https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html)
>       that could be leveraged?
>
>     - What is the minimum set of materials we or another group
>       would need to pull together to make this specific
>       information about MDQ and per-entity consumable by a
>       project/vendor like Okta or Ping or ?
>
>     I have started a wiki page with "Risks" and "Opportunities" at
>
>     https://spaces.internet2.edu/x/WIEABg
>
>     and have added this in particular as an opportunity with a
>     link to your email in the archive.
>
>     Thanks,
>
>     Scott K
>
>