signing IDP metadata
Herron, Joel D
herronj at uww.edu
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.
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
* 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
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 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
Highly unlikey as that would break the service for all their
non-signing customers (i.e., the other 99.9999%). ;)
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...
More information about the users