<div dir="ltr"><div>Hi Scott,</div><div><br></div><div>I'm aware of how metadata is usually created. I've also already used the XMLSecTool to sign metadata of an example federation.</div><div><br></div><div>The scenario consists of a single IdP and a single SP with both not being in a federation. I'm trying to distribute the metadata (automatically signed) in both directions via https. </div><div><br></div><div>On the SP side it's possible to sign the metadata with the signing attribute of the MetadataGenerator. </div><div><br></div><div>"<Handler type="MetadataGenerator" Location="/Metadata" signing="true"/>"</div><div>Reference: <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPHandler#NativeSPHandler-Attributes">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPHandler#NativeSPHandler-Attributes</a></div><div><br></div><div>So on the IDP side it's just required to have the previously exchanged public key of the SP to verify the SP metadata.</div><div><br></div><div>Is there any equivalent way to automatically sign the metadata for the IdP?</div><div>I hope this explains it better.<br></div><div><br></div><div>Larissa</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-21 16:53 GMT+02:00 Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 6/21/17, 10:35 AM, "users on behalf of Larissa Riedel" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:larissa.riedel88@gmail.com">larissa.riedel88@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
> Does the IdP also comes with the capability to automatically sign his metadata?<br>
<br>
</span>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.<br>
<span class=""><br>
> Can anybody explain the procedure to me? I am a bit confused with all the certificates and signatures :-).<br>
<br>
</span>There is no "procedure", it's art, not science, and depends on the situation.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Scott<br>
<br>
[1] <a href="https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/display/CONCEPT/<wbr>TrustManagement</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>