Signing metadata
Cantor, Scott
cantor.2 at osu.edu
Wed Jun 21 10:53:58 EDT 2017
On 6/21/17, 10:35 AM, "users on behalf of Larissa Riedel" <users-bounces at shibboleth.net on behalf of larissa.riedel88 at gmail.com> wrote:
> I know that the SP has the capability to sign his metadata, so the IdP only has to receive my public key to verify it.
> Does the IdP also comes with the capability to automatically sign his metadata?
Neither the SP nor IdP has a capability meant to be used in the way you're describing. Metadata is meant to be maintained separately from a software configuration to be of proper use, and signing the metadata is a separate step that depends on the trust model involved, number of IdPs and SPs, etc.
> Can anybody explain the procedure to me? I am a bit confused with all the certificates and signatures :-).
There is no "procedure", it's art, not science, and depends on the situation.
But you should never generate metadata automatically (other than as input to a manual review and update), and if possible look at using a third party source for metadata that decouples the IdP and the SP from any direct interactions or exchanges of keys.
If you're hosting, say, an IdP's metadata for an internal collection of systems and want to sign it, there's a Java tool distributed by the project called xmlsectool that can do it. You would need to sign it daily and consumers need to apply proper constraints to limit the validity window, or you've made revocation impossible.
Start with [1]. If that doesn't make sense to you, find a federation to leverage to help you, or treat the whole exercise as manual and exchange the metadata out of band by hand, understanding the implications of that. Automating anything implies a degree of understanding of the security implications, which can be very complex.
-- Scott
[1] https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement
More information about the users
mailing list