Unknown or Unusable Identity Provider

Peter Schober peter.schober at univie.ac.at
Tue Dec 3 14:07:42 EST 2019

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


More information about the users mailing list