Is there a checklist for the metadata file?

[Cantor, Scott]

On 3/29/15, 5:17 PM, "Joe Edwards" <joee at uw.edu> wrote:

>I manage the pubcookie server for our organization.
>We need to move to shibboleth. Now, that I have shibboleth
>3.1.1 working on our dev and test servers, I need to get
>to the next level.
>
>Now, to learn enough to get our future production shibboleth
>server joined to a federation.

Well, internal/enterprise use and federated use are fairly different use cases. Enterprise use can be managed much less "formally" than the way federations operate, but there are still differences between SAML and systems that are symmetric key based or that don't generally want to register services at all.

I don't use InCommon for on-campus systems, and I don't supply the metadata for our IdP to them with it. I host the metadata file, but I also sign it every morning, and it expires every few days, and the (Shibboleth) SPs check all of that when they load it every few hours.

I register SPs by hand and generate the metadata for Shibboleth SPs with a script because I know what it looks like. I collect all the contacts and keys when I get the registrations. If I had more time, I'd automate all that, but in practice it just doesn't take up all that much time.

InCommon is used for all the systems that aren't on campus. That metadata is separate, and I can deploy things on campus in my hosted metadata that I haven't made publically available by not registering it with the federation. That has been useful on several occasions.

The reason why you don't generate metadata is you have no control. You can't use it to publish signing keys ahead of deploying them, and you can't *unpublish* endpoints you don't want SPs using but that you still have to operate because of SPs that are hardcoding endpoints or don't use metadata at all.

-- Scott