SP Startup takes 20+ minutes

[Scott Koranda]

> On Mon, May 2, 2016 at 8:50 AM, Scott Koranda <skoranda at gmail.com> wrote:
> >> On Fri, Apr 29, 2016 at 8:54 PM, Scott Koranda <skoranda at gmail.com> wrote:
> >>
> >> 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.
> 
> Earlier in the thread, you show how to use curl to GET the metadata.
> So the cron job dictates when the file is refreshed regardless of
> whether or not the file has changed. OTOH, Shibboleth (both SP and
> IdP) will skip a refresh attempt if the file has not changed.

I see. I thought your comment was specific to the SP metadata
configuration in your note and not the earlier part of the
thread.

I understand your comments.

> > 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.
> 
> I wouldn't be surprised if a lot of SPs were doing this now but I
> would be surprised if I found out the same were true for IdP
> deployments. May I ask what makes you think this is so?

When the InCommon metadata feed expanded to include eduGAIN
both SPs and IdPs were affected. Some were caught off guard,
not for any lack of warning from you and the federation.

The related issues for the SP and IdP are different. I did not
mean to say they were the same.

The symptoms, however, could be the same. Longer startup times
to download the metadata feed and apply filters.

Some deployments react to this by downloading a static copy of
the file and then removing filters. Others just remove
filters. 

I am not arguing any technical details or how each individual
issue may be worked around. 

I am only pointing out what you already know--when faced with
an issue affecting production operation some IdP and SP
administrators who do not fully understand the trust model
will make undesirable compromises.

> > In my opinion a documented work around with a detailed
> > explanation of caveats is better then the altenatives
> 
> Perhaps you're right but this is still cause for concern. The fact
> that we're even having this discussion is cause for concern.

I think it is being addressed by the Shibboleth developers.

> > 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).
> 
> I'm aware of the SP issue but not the IdP issue. Can you provide a
> pointer (or an explanation)?
> 

I was thinking specifically of

https://issues.shibboleth.net/jira/browse/OSJ-160

and the thread

http://marc.info/?l=shibboleth-dev&m=145925735703621&w=2

Again, I understand that is a different technical issue then
the SP issue that this thread initially addressed and I am not
arguing that they are the same.

I am only arguing that in my opinion documenting this type of
work around is better then not documenting it. But I fully
acknowledge there are tradeoffs to that approach.

Thanks,

Scott K