metadata generation

[Jeff Masiello]

Actually, I suppose, as we're writing the install scripts we can just grab the IdP metada and stick on the SP as they spin up. And we can script any midifications ot the SP data from info collected in the install process.


Subject: Re: metadata generation

So I should, for the IdP, create a location that just has a build MD file and have the SP's grab that as they spin up?

I would ask SP's to supply metadata to you.  If they are not super technical, consider pulling their metadata from their /Shibboleth.sso/Metadata handlers as they register with you and using that as the basis for a pile-of-SP's metadata file on the IdP node.  You could host it for everyone but only the IdP needs to load it.

all-the-pretty-things.xml:
<EntitiesDecriptor Name="allThePrettyThings">
   <EntityDescriptor id="SP1" />
   <EntityDescriptor id="SP2" />
   <EntityDescriptor id="SP3" />
</EntitiesDescriptor>

/shibboleth-idp/conf/relying-party.xml:
<MetadataProvider id="allThePrettyThings" xsi:type="FilesystemMetadataProvider" metadataFile="/path/to/all-the-pretty-things.xml" />

There are multiple ways to manage this, from shell scripts or XSLT operating on folders of metadata files to vi to full-blown federation management GUI's with workflows.  If this will not change much and you know XML syntax, vi will be fastest.


I guess my next question is, and I haven't read all the helpful links sent to me yet, is what, if any, are the security ramifications of allowing essentially open access to the metadata file?

"Open access"?  Really bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140620/1a2f7f09/attachment.html