SP Startup takes 20+ minutes

[Scott Koranda]

> On Fri, Apr 29, 2016 at 8:54 PM, Scott Koranda <skoranda at gmail.com> wrote:
> >>
> >>     Then we configured the SP to no longer run the signature
> >>     filter on the file
> >>
> >> Can you provide a working example on how to disable it?
> >
> > We changed
> >
> > <MetadataProvider type="XML" url="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFilePath="InCommon-metadata.xml" maxRefreshDelay="28800" legacyOrgNames="true">
> >     <MetadataFilter type="Signature" certificate="/etc/shibboleth/inc-md-cert.pem"/>
> >     <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200" />
> >     <MetadataFilter type="Blacklist" matcher="EntityAttributes">
> >       <saml:Attribute Name="http://macedir.org/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> >         <saml:AttributeValue>http://refeds.org/category/hide-from-discovery</saml:AttributeValue>
> >       </saml:Attribute>
> >     </MetadataFilter>
> > </MetadataProvider>
> >
> > to be instead
> >
> > <MetadataProvider type="XML" file="/var/cache/shibboleth/InCommon-metadata-verified.xml" legacyOrgNames="true">
> >     <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200" />
> >     <MetadataFilter type="Blacklist" matcher="EntityAttributes">
> >       <saml:Attribute Name="http://macedir.org/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
> >         <saml:AttributeValue>http://refeds.org/category/hide-from-discovery</saml:AttributeValue>
> >       </saml:Attribute>
> >     </MetadataFilter>
> > </MetadataProvider>
> 
> Scott, you already know this but you lose HTTP Conditional GET with

Sorry, I do not understand. There is no GET with this approach
so I do not see how I lose Conditional Get.

The verified (signature checked) metadata file is being loaded
from the file system.

> this approach. I have a script that makes up for that
> (https://gist.github.com/trscavo/5fb0ce26796da9321e84) but that's not
> the main reason why I replied.

Thanks.  

Your script, when combined with xmlsec1 for signature
checking, would be a better solution.

> The rest of this message is directed at the larger dev community, not Scott.
> 
> I was shocked when I first saw the above configs, and then I realized
> I was reading on the dev list (not the users list) and my reaction
> subsided. Still, I think it's cause for concern that such workarounds
> are even required, let alone published.
> 
> Like others here, I've made an effort over the years to document
> secure MetadataProvider examples in the wiki. The above workaround is
> not in that category since it can be easily misinterpreted and misused
> by a naive user. I will do what I can to keep that example out of the
> wiki but I suppose it's just a matter of time before the it finds its
> way onto the users list. <sigh>

I understand your concern.

I think, however, you underestimate the number of deployments
that have solved the issue by simply turning off all signature
checking. Both SPs and IdPs.

In my opinion a documented work around with a detailed
explanation of caveats is better then the altenatives until
the operation of the SP and IdP changes (note the JIRA issue
is already being updated for the SP, and perhaps the IdP,
though I am not tracking that directly).

Thanks,

Scott K