InCommon metadata support

[Jeffrey Eaton <>]

> On Feb 19, 2016, at 3:28 PM, Tom Scavo 
> <>
>  wrote:
> 
> On Thu, Feb 18, 2016 at 7:06 PM, Jeffrey Eaton 
> <>
>  wrote:
>> 
>>> On Feb 18, 2016, at 12:52 PM, Tom Scavo 
>>> <>
>>>  wrote:
>>> 
>>> try the export aggregate. See: https://spaces.internet2.edu/x/vACVBQ
>>> 
>>> The export aggregate currently has 402 of the 424 total IdPs in the
>>> InCommon Federation. Not sure that meets your production needs but at
>>> least it might be useful for experimental purposes.
>> 
>> Loading that aggregate complete in 2 seconds, and the resulting shibd 
>> process only takes up about 40 MB of RAM.  That actually seems like a very 
>> reasonable compromise.  I suppose ideally, InCommon would produce 
>> something like this with all of the InCommon IDPs (I’m not sure which 22 
>> are missing, but I’d imagine someone would find it useful to have the full 
>> set of InCommon only IDPs available.
> 
> I regret having mentioned the export aggregate. I'm putting my
> Operations hat on now...
> 
> The export aggregate is meant to be consumed by other federations,
> that is, the export aggregate is used for interfederation purposes. It
> is NOT intended for SAML IdP and SP deployments.

I will stop using the export aggregate as soon as I can.

I would still like to see InCommon provide an aggregate of just the InCommon 
IDPs, intended for consumption by SPs which are in InCommon but not eduGAIN.  
Just doing this will significantly reduce the waste of CPU/memory that the 
current full aggregate causes,.  For  the systems in question which are 
rather resource constrained, this makes the difference between working fine, 
and not working at all because shibd eats all of the available RAM (and 
eventually triggering the Linux kernel OOM killer to kill off shibd).

> 
>> I’m still evaluating what we’re going to recommend to our SP operators, 
>> but in the worst case, I can have them use the export aggregate
> 
> No, please don't do that. Ops will NOT support that use case, meaning
> Ops will NOT guarantee the location and content of the export
> aggregate. That aggregate is intended for eduGAIN, and if we need to
> change it on short notice to accommodate eduGAIN, we will do so,
> without regard for other metadata clients.
> 
>> or my split and re-signed IDP-only aggregate, with no further changes 
>> needed from the InCommon side.
> 
> Well, that works from my PoV but I'm not sure it's optimal. Before I
> suggest other options, I need to ask a question about your
> environment:
> 
> CMU has 100s of SPs in InCommon metadata (literally) but is it true
> that most (or all?) of these SPs are what I call Enterprise SPs? Do
> these SPs interact with the CMU IdP only?
> 
> I'm trying to understand if any of these SPs need to interoperate with
> arbitrary IdPs (i.e., IdPs other than the CMU IdP).

Many of them probably don't need to be in InCommon at all, because they only 
allow logins from our IDP.  The decision to register all of our SPs in the 
InCommon metadata was a past strategic plan that we are reevaluating. 

-jeaton