Unknown or Unusable Identity Provider

[Conroy Baltzell]

I did install it through yum as recommended here:
https://wiki.shibboleth.net/confluence/display/SP3/RPMInstall. I just
restarted it again for like the 4th time today and now it works again. So I
have no idea what changed but it's working now. Thank you for your help.
And just to help me with best practices are you saying I should just get my
metadata from http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml
and then filter it to my institution?

On Tue, Dec 3, 2019 at 2:08 PM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Conroy Baltzell <baltzell at umich.edu> [2019-12-03 19:56]:
> > (and I'm hesitant to update anything on the production server
> > without testing it on the dev server).
>
> The way I see it your internal servers are already 100% broken by not
> knowing your own IDP. Not sure how things could get worse.
>
> You don't provide any information on how you installed the SP but if
> you did anything other than adding the yum repo as per the docs and
> installed via yum then you're probably Doing It Wrong.
>
> > I didn't realize the SP uses cached metadata so that seems to be the
> > most likely suspect. I don't think the problem is
> > https://shibboleth.umich.edu/md/umich-prod-idps.xml because a lot of
> > sites use that and none of them seem to be down. How would I tell if
> > it was an expired validUntil?
>
> I only mentioned that because you said all your Shib SPs refused to
> know your IDP around the same time and that you thought no software
> changes were involved.
>
> Right now the above metadata is not expired but you can look what
> affected SPs have in the file system, of course.
> (/var/cache/shibboleth or somewhere in that vicinity).
>
> More fundamentally: I personally recommend to our institutions to pull
> IDP metadata from the federation aggregate (and filter it down to the
> one institutional IDP is desired, for local-only SPs; with MDQ even
> that filtering goes away) because then institutions doesn't have to
> implement secure, regular signing processes only for the metadata of a
> single IDP entity.
> But then I'm the federation operator, so I'm probably biased.
>
> -peter
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20191203/0374cac9/attachment.html>