InCommon metadata support

[Tom Scavo <>]

On Mon, Feb 22, 2016 at 2:13 PM, Jeffrey Eaton 
<>
 wrote:
>
>> On Feb 19, 2016, at 3:28 PM, Tom Scavo 
>> <>
>>  wrote:
>>
>>
>> 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.

Thank you, Jeffrey.

> 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 will discuss this with the rest of the Ops team and InCommon TAC.
I'll write back to the list ASAP.

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

Okay, but I'm still wondering if CMU has any SPs in metadata that
require all InCommon IdPs or are all your SPs interoperating with the
CMU IdP exclusively?

Thanks,

Tom