Shibboleth(3.2.3) : Parsing of the Incommons-Medata.xml taking huge amount of time

[IAM David Bantz]

 Are you perhaps using metadata filters on each of thousands of entities in
the federation aggregate rather than simply validating the signature
applied to the aggregate?



On 13Apr2022 at 09:17:42, Siddharth Satyakam via users <users at shibboleth.net>
wrote:

> Hello All,
>
>
>
> When we are restarting our Shibd.service during regular maintainance, we
> are facing a issue with the parsing of the Incommons-metadata.xml file.
> While checking of signature after downloading of the xml file, taking a
> very long peroid of time while applying metadata filter for signature i.e.
> close to 20 mins downtime
>
> ……………………………………………………………………………………………………………………………………………………………….
>
> ……………………………………………………………………………………………………………………………………………………………….
>
> ……………………………………………………………………………………………………………………………………………………………….
>
> 2022-04-11 16:27:49 INFO Shibboleth.Application : auto-configuring Logout
> initiation for protocol (Local)
>
> 2022-04-11 16:27:49 INFO Shibboleth.Application : adding LogoutInitiator
> of type (Local) to chain (/Logout)
>
> 2022-04-11 16:27:49 INFO Shibboleth.Handler.DiscoveryFeed : feed files
> will be cached in /var/cache/shibboleth/
>
> 2022-04-11 16:27:49 INFO Shibboleth.Application : building
> MetadataProvider of type XML...
>
> 2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building
> MetadataFilter of type RequireValidUntil
>
> 2022-04-11 16:27:49 INFO OpenSAML.MetadataProvider : building
> MetadataFilter of type Signature
>
> 2022-04-11 16:27:49 INFO XMLTooling.SecurityHelper : loading
> certificate(s) from file (/etc/shibboleth/inc-md-cert.pem)
>
> 2022-04-11 16:27:49 INFO XMLTooling.CredentialResolver.File : no private
> key resolved, usable for verification/trust only
>
> 2022-04-11 16:28:00 INFO OpenSAML.MetadataProvider.XML : loaded XML
> resource (https://md.incommon.org/InCommon/InCommon-metadata.xml)
>
> 2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata
> filter (RequireValidUntil)
>
> 2022-04-11 16:28:06 INFO OpenSAML.MetadataProvider : applying metadata
> filter (Signature)
>
>
>
> In January last month itself we had to increase the timeout for starting
> of the service from 5 to 10mins and now it has increased to 20 mins in such
> a short time.
>
>
>
> Moreover when we checked the CPU usage at this time of outage we saw that
> the shibd service was consuming 100% of the single thread CPU core
> consistently.
>
>
>
> As we cannot have such a long downtime, and also at a such a constant
> sharp increase in the downtime. We wanted for some inputs in questions:
>
>    - Is this issue standard, faced by everyone??
>    - Is there any parameter in the shibboleth2.xml; altering which could
>    enable the shibd.service to use more numner of CPU nodes if this issue is
>    due to the lack of CPU resouces??
>    - If not will shibd.service support the use of hyper-threading; i.e.
>    multiple threads on a single core where the service is being started to
>    illiminate the chance that this parsing delay is due to the CPU resouce
>    shortage??
>    - Will increase in the clock rate i.e. Mhz of the CPU help in this
>    case??
>    - Is there a way to skip this and us to choose when to parse the newly
>    downloaded xml, so as to reduce downtime??
>    - And are there any other solutions that anyone has implemented that
>    has worked around this issue??
>
>
>
> Thank you for any inputs, relating to the same.
>
>
>
> Yours Sincerely,
>
> Siddharth Satyakam
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> 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/20220413/128cf951/attachment.htm>