signing IDP metadata

Thu Apr 28 23:46:12 UTC 2022

Thanks peter, that’s what I assumed.

I wish we could just use the incommon MDQ service, but in the infinite wisdom of this former maintainer we have two entity IDs one for incommon which only 5% of our SPs use and our primary  which is fed by this custom aggregator/generator. Yeah it’s a mess.

--Joel

From: users <users-bounces at shibboleth.net> on behalf of Peter Schober via users <users at shibboleth.net>
Date: Thursday, April 28, 2022 at 4:28 PM
To: users at shibboleth.net <users at shibboleth.net>
Cc: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: signing IDP metadata
*EXTERNAL EMAIL*

* Herron, Joel D <herronj at uww.edu> [2022-04-28 23:12]:
> The previous implementor of our IDP signed both of our
> idp-metadata.xml files (standard and 4096 certs) with a custom xml
> generator which I’m looking to retire.

If you wanted to keep signing (see below9) you can always use
XmlSecTool, https://shibboleth.atlassian.net/wiki/spaces/XSTJ3/overview
or the SP's samlsign or other "non-custom" tools.

> Is this a common practice?  I’m not seeing anything in the
> documentation that suggests that’s a something to even consider
> doing. I can see the benefits in theory but that would require SPs
> to actually check the signing.

This. Also, you'd want to sign+expire[1] then, meaning you'd
periodically (e.g. daily) add/set EntityDescrptor/@validUntil a few
days/weeks into the future, sign and publish.

But why self-publish your IDP's metadata at all? I.e., why not point
the SP to the *signed*, constantly *updated* copy of your IDP's
metadata in InCommon's MDQ service?

> If I were to not sign it going forward I assume the risk would be if
> some SP actually implemented the signing check it would fail for
> them.

Highly unlikey as that would break the service for all their
non-signing customers (i.e., the other 99.9999%). ;)

-peter
--
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/20220428/cfe46e69/attachment.htm>