Unknown or Unusable Identity Provider

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Unknown or Unusable Identity Provider

conroy
I know this topic has been discussed a few times in a few different ways, but
none of it fixed my problem, so hopefully I'm not repeating,
but...Everything was working fine yesterday and today all of my servers that
are running Shibboleth are giving an error page saying: "Unknown or Unusable
Identity Provider." To my knowledge there was no patches or changes to any
of the servers. According to the shibd.logs the problem seems to be:

2019-12-03 12:44:30 ERROR XMLTooling.libcurl.InputStream : error while
fetching https://shibboleth.umich.edu/md/umich-prod-idps.xml: (59) Unknown
cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
2019-12-03 12:44:30 ERROR XMLTooling.libcurl.InputStream : on Red Hat 6+,
make sure libcurl used is built with OpenSSL
2019-12-03 12:44:30 ERROR XMLTooling.ParserPool : fatal error on line 0,
column 0, message: internal error in NetAccessor
2019-12-03 12:44:30 ERROR OpenSAML.MetadataProvider.XML : error while
loading resource (https://shibboleth.umich.edu/md/umich-prod-idps.xml): XML
error(s) during parsing, check log for specifics
2019-12-03 12:44:30 WARN OpenSAML.MetadataProvider.XML : adjusted reload
interval to 3000 seconds
2019-12-03 12:44:30 WARN OpenSAML.MetadataProvider.XML : trying backup file,
exception loading remote resource: XML error(s) during parsing, check log
for specifics
2019-12-03 12:44:30 INFO OpenSAML.MetadataProvider.XML : using local backup
of remote resource
2019-12-03 12:44:30 INFO OpenSAML.MetadataProvider.XML : loaded XML resource
(/var/cache/shibboleth/umich-prod-idps.xml)
2019-12-03 12:44:30 ERROR OpenSAML.MetadataProvider.XML : metadata instance
was invalid at time of acquisition
2019-12-03 12:44:30 CRIT OpenSAML.MetadataProvider.XML : maintaining
existing configuration, error reloading resource
(https://shibboleth.umich.edu/md/umich-prod-idps.xml): Metadata instance was
invalid at time of acquisition.

I'm running RHEL 7.7 so I looked at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRH6 but:
1. I don't have a /etc/sysconfig/shibd or
/etc/systemd/system/multi-user.target.wants/shibd.service file. There are
other related files, but not those 2.
2. The current libcurl in /opt/shibboleth/ is libcurl.so.4.5.0 which is not
the most recent, but I'm hesitant to update it without knowing more because
that might be the "correct" version for my setup.
3. I don't see how either of those problems could change overnight.

Any help or insight would be greatly appreciated.

Thanks,
Conroy



--
Sent from: https://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Cantor, Scott E.
> 1. I don't have a /etc/sysconfig/shibd or
> /etc/systemd/system/multi-user.target.wants/shibd.service file. There are
> other related files, but not those 2.

Then your system was corrupted because the packages provided by the project would install them and that's how the packages ensure the right version of libcurl is used.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Peter Schober
In reply to this post by conroy
* conroy <[hidden email]> [2019-12-03 19:17]:
> I know this topic has been discussed a few times in a few different ways, but
> none of it fixed my problem, so hopefully I'm not repeating,
> but...Everything was working fine yesterday and today all of my servers that
> are running Shibboleth are giving an error page saying: "Unknown or Unusable
> Identity Provider." To my knowledge there was no patches or changes to any
> of the servers.

So what version of the SP are you running (or quoting the logs from)?
If yesterday "Everything was working fine yesterday" and today none
your Shib SPs can connect to
https://shibboleth.umich.edu/md/umich-prod-idps.xml then I'd say
either that server has seen a change or all your SP servers -- *but*
if that is related to an expired validUntil (there's no sign of that
in your logs, but that doesn't mean that didn't happen as well) this
may have happened a few days ago. The SP locally caches and continue
to use metadata as long as it's valid, so all SPs not knowing an IDP
at the same point in time could well be indicative of such a problem.

> I'm running RHEL 7.7 so I looked at
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRH6 but:

Not that it matters for your question but SP v2 is out of support. Has
been for quite a while. Of course you may be looking at the SP docs by
mistake?

> 1. I don't have a /etc/sysconfig/shibd or
> /etc/systemd/system/multi-user.target.wants/shibd.service file. There are
> other related files, but not those 2.

I don't have a running RHEL/CentOS 7 system atm so can't check.

> 2. The current libcurl in /opt/shibboleth/ is libcurl.so.4.5.0 which
> is not the most recent, but I'm hesitant to update it without
> knowing more because that might be the "correct" version for my
> setup.

Configuring the correct yum repository and simply 'yum install'ing and
occasionally 'yum update'ing the software should be all that it takes,
without ever having to ask yourself the above question ("what libcurl
version should I be running").

> 3. I don't see how either of those problems could change overnight.

See my take on that above.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

conroy
Thanks for the quick responses. I'm running shibboleth 3.0.4. I was accidentally on the SP2 support pages, but in this case there doesn't seem to be much of a difference to V3  https://wiki.shibboleth.net/confluence/display/SP3/LinuxRH6. I can try updating shibboleth, but I just installed it on a new server less than a month ago so I don't think that's the issue (and I'm hesitant to update anything on the production server without testing it on the dev server). 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? 

On Tue, Dec 3, 2019 at 1:43 PM Peter Schober <[hidden email]> wrote:
* conroy <[hidden email]> [2019-12-03 19:17]:
> I know this topic has been discussed a few times in a few different ways, but
> none of it fixed my problem, so hopefully I'm not repeating,
> but...Everything was working fine yesterday and today all of my servers that
> are running Shibboleth are giving an error page saying: "Unknown or Unusable
> Identity Provider." To my knowledge there was no patches or changes to any
> of the servers.

So what version of the SP are you running (or quoting the logs from)?
If yesterday "Everything was working fine yesterday" and today none
your Shib SPs can connect to
https://shibboleth.umich.edu/md/umich-prod-idps.xml then I'd say
either that server has seen a change or all your SP servers -- *but*
if that is related to an expired validUntil (there's no sign of that
in your logs, but that doesn't mean that didn't happen as well) this
may have happened a few days ago. The SP locally caches and continue
to use metadata as long as it's valid, so all SPs not knowing an IDP
at the same point in time could well be indicative of such a problem.

> I'm running RHEL 7.7 so I looked at
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRH6 but:

Not that it matters for your question but SP v2 is out of support. Has
been for quite a while. Of course you may be looking at the SP docs by
mistake?

> 1. I don't have a /etc/sysconfig/shibd or
> /etc/systemd/system/multi-user.target.wants/shibd.service file. There are
> other related files, but not those 2.

I don't have a running RHEL/CentOS 7 system atm so can't check.

> 2. The current libcurl in /opt/shibboleth/ is libcurl.so.4.5.0 which
> is not the most recent, but I'm hesitant to update it without
> knowing more because that might be the "correct" version for my
> setup.

Configuring the correct yum repository and simply 'yum install'ing and
occasionally 'yum update'ing the software should be all that it takes,
without ever having to ask yourself the above question ("what libcurl
version should I be running").

> 3. I don't see how either of those problems could change overnight.

See my take on that above.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Cantor, Scott E.
On 12/3/19, 1:56 PM, "users on behalf of Conroy Baltzell" <[hidden email] on behalf of [hidden email]> wrote:

>  How would I tell if it was an expired validUntil?

You're misunderstanding the point if you're imagining the source is the proble,. The metadata is expired, and you can see that in the cached copy in /var/cache/shibbleth. Your logs have been logging the libcurl error for an indeterminate amount of time. The metadata is expired because the server began failing to refresh its copy of the metadata and once the metadata expired, the other error appeared.

The point at which the corruption occurred is the point at which shibd was restarted after improper removal of the files installed by the RPM package, and it would have begun logging the actual error leading to the metadata expiring at that point.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Peter Schober
In reply to this post by conroy
* Conroy Baltzell <[hidden email]> [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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

conroy
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 <[hidden email]> wrote:
* Conroy Baltzell <[hidden email]> [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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Cantor, Scott E.
On 12/3/19, 2:41 PM, "users on behalf of Conroy Baltzell" <[hidden email] on behalf of [hidden email]> wrote:

> 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?

Only your IdP operations staff can speak to that. There is no guarantee that the metadata provided to a federation is the intended metadata for use on campus or doesn't differ at times in deliberate ways.
 
Even if you did, it wouldn't have changed the outcome, and if you were to use InCommon's you would be using the Dynamic provider and the per-entity service.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Mak, Steve
In reply to this post by conroy

Conroy,

 

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? 

 

Not all SPs honor the validUntil correctly.  Shib SP is one that does.  It will 100% refuse to load an idp metadata if the file says it's expired.

 

The workaround you can use to get your SP up and running in the interim, until the metadata publishing gets fixed or deprecated, you can manually pulldown the idp metadata, delete the validUntil, and then save it to a local file and have your SP use that local file instead.  There's no real security risk here assuming the idp metadata is good except for validUntil.

 

- Steve Mak


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Alan Buxey
In reply to this post by conroy
Hi

That error is expected if the shib Daemon was run using the default system libcurl

The service scripts set the LD_LIBRARY_PATH value to include the packages libcurl (built with required things) in /opt/shibboleth/lib64 or wherever it is on that OS these days ;) - so if you want to run it directly in foreground mode with debugging etc etc you need to invoke the Daemon with correct LD_LIBRARY_PATH set

alan

On Tue, 3 Dec 2019, 18:17 conroy, <[hidden email]> wrote:
I know this topic has been discussed a few times in a few different ways, but
none of it fixed my problem, so hopefully I'm not repeating,
but...Everything was working fine yesterday and today all of my servers that
are running Shibboleth are giving an error page saying: "Unknown or Unusable
Identity Provider." To my knowledge there was no patches or changes to any
of the servers. According to the shibd.logs the problem seems to be:

2019-12-03 12:44:30 ERROR XMLTooling.libcurl.InputStream : error while
fetching https://shibboleth.umich.edu/md/umich-prod-idps.xml: (59) Unknown
cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
2019-12-03 12:44:30 ERROR XMLTooling.libcurl.InputStream : on Red Hat 6+,
make sure libcurl used is built with OpenSSL
2019-12-03 12:44:30 ERROR XMLTooling.ParserPool : fatal error on line 0,
column 0, message: internal error in NetAccessor
2019-12-03 12:44:30 ERROR OpenSAML.MetadataProvider.XML : error while
loading resource (https://shibboleth.umich.edu/md/umich-prod-idps.xml): XML
error(s) during parsing, check log for specifics
2019-12-03 12:44:30 WARN OpenSAML.MetadataProvider.XML : adjusted reload
interval to 3000 seconds
2019-12-03 12:44:30 WARN OpenSAML.MetadataProvider.XML : trying backup file,
exception loading remote resource: XML error(s) during parsing, check log
for specifics
2019-12-03 12:44:30 INFO OpenSAML.MetadataProvider.XML : using local backup
of remote resource
2019-12-03 12:44:30 INFO OpenSAML.MetadataProvider.XML : loaded XML resource
(/var/cache/shibboleth/umich-prod-idps.xml)
2019-12-03 12:44:30 ERROR OpenSAML.MetadataProvider.XML : metadata instance
was invalid at time of acquisition
2019-12-03 12:44:30 CRIT OpenSAML.MetadataProvider.XML : maintaining
existing configuration, error reloading resource
(https://shibboleth.umich.edu/md/umich-prod-idps.xml): Metadata instance was
invalid at time of acquisition.

I'm running RHEL 7.7 so I looked at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxRH6 but:
1. I don't have a /etc/sysconfig/shibd or
/etc/systemd/system/multi-user.target.wants/shibd.service file. There are
other related files, but not those 2.
2. The current libcurl in /opt/shibboleth/ is libcurl.so.4.5.0 which is not
the most recent, but I'm hesitant to update it without knowing more because
that might be the "correct" version for my setup.
3. I don't see how either of those problems could change overnight.

Any help or insight would be greatly appreciated.

Thanks,
Conroy



--
Sent from: https://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-f1660767.html
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Unknown or Unusable Identity Provider

Cantor, Scott E.
On 12/4/19, 4:19 AM, "users on behalf of Alan Buxey" <[hidden email] on behalf of [hidden email]> wrote:

> That error is expected if the shib Daemon was run using the default system libcurl

This is, BTW, mercifully over and done with in RH8.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]