InCommon metadata support

[Jeffrey Eaton <>]

I've been doing some testing.

I wrote some scripts to take the InCommon metadata file, split it into two 
files - one containing just SPs, the other containing IDPs, and then signed 
them both with my own certificate (with the same sha256 signatures).  Loading 
just the IDP metadata file (which is about 13MB) and starting shibd takes 
about 20 seconds, compared to over a minute for loading the whole InCommon 
file.  Furthermore, the resident size of the shibd process drops from 256MB 
with the full InCommon file, down to about 120MB with just the IDP metadata 
loaded.

Is there any particular reason why InCommon puts all of the SPs and IDPs 
together into one big metadata file?  As I understand it, the Service 
Provider only needs to load the metadata for IDPs, and vice-versa, so there's 
a lot of bloat in the file that doesn't really need to be there for normal 
operations.

-jeaton

> On Feb 16, 2016, at 6:41 PM, Jeffrey Eaton 
> <>
>  wrote:
> 
>> 
>> One thing we could do, I suppose, is generate an aggregate on MDQ-beta
>> without the namespace optimization and see if that matters. Jeffrey,
>> if we did that, would you be willing to test against that new
>> aggregate? (It would have the same content, just different namespace
>> declarations.)
>> 
>> Tom
> 
> Sure, I’m willing to test anything I can.  I do have a pretty 
> straightforward testbed, where I load only the InCommon metadata with 
> mostly otherwise stock configuration.  It is using an output HTTP proxy, 
> but the issue seems to occur with or without that, because one of my tests 
> was to just save the metadata locally, and load it using the file directly 
> instead of pulling over HTTP at all.
> 
> -jeaton
> 
>