Metadata file for SP Server

[Cantor, Scott]

On 7/15/13 8:24 PM, "Roy Spectech" <roygspectech8 at gmail.com> wrote:
>
>    We used something like this URL to see what our customers would see:
>
>       https://metaserve.example.com/Shibboleth.sso/Metadata

You should be in control of the metadata you give to customers or
federations, and using that mechanism makes that essentially impossible
unless you have experience with the software and know when to stop using
it and switch to manual.

The primary reason why was discussed (again) on the list earlier today.

So no, your customers should never use that.

>This seems like a very complicated file. We certainly do not want to get
>it wrong.

Apache is also very complicated, but not everything that can be used has
to be.

The way not to get it wrong is to not rely on a generated copy, so you can
verify what's in it and add things like contact information, UIInfo
extensions, requested attributes, and things like that as you need them.

>    Is there a general "Metadata Generator" out here that will look at our
>    shibboleth2.xml, attribute-map, etc., and make a better attempt at a
>"good"
>    metadata file?

No. The metadata it generates is not "bad", it's simply incomplete and
tied far too intimately to the configuration. The point of metadata is to
support graceful configuration changes. It can't do that if it changes
instantly (or only) when the configuration changes.

>    Failing that, since some day we might want to apply to a Federation
>(doing
>    just one metadata is fine with us), is there an accepted
>format/template we
>    can download as a starting point? Or are there examples of what would
>be
>    considered best practice Metadata files?

Different federations have different guidelines for metadata content. Some
like InCommon don't even use the XML to register systems. In today's
federations, the primary extension needed to smooth interactions is the
UIInfo extension.

http://wiki.oasis-open.org/security/SAML2MetadataUI

In a few years the algorithm support extension will probably be extremely
important, but it's very irrelevant today, particularly if you're an SP,
since nothing supports the extension.

https://wiki.oasis-open.org/security/SAML2MetadataAlgSupport

>
>    Another seemingly silly question. Once we get the file the way we
>want it,
>    where is it supposed to go in the file structure?

Web servers don't care about file structure. The best practice is that
your entityID resolve  to the metadata. Other than that, it doesn't matter.

Just hosting metadata is not a trust management strategy. If you were to
offer that to me, I would simply say "so what?" and ask for a phone number
to call, listed on your web site, to verify your metadata and
certificate(s). That's why federations exist, in which case these
questions become moot, because your customers wouldn't get your metadata
directly from you.

In fact, the paradox of federations is that I don't have to join one to
rely on one to get your metadata. Joining a typical federation is not
materially different than getting an Extended Validation TLS certificate.

-- Scott