Per-Entity Metadata Working Group

[Nick Roy <>]

Sorry for the top-down reply, someone recently decided it would be a good 
idea to make Word the editor for Outlook and totally hosed the ability of 
that client to do in-line replies.

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).

Thanks,

Nick

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