SP will not provide metadata file: maybe it's not necessary?

[Cantor, Scott]

> We are currently working with an external SP to authenticate against our
> IdP. This vendor insists that they don't need to give us metadata, only
> an entity ID, an SSO endpoint, and a desired nameid format. They don't
> sign requests or want responses encrypted; they are not part of InCommon
> or any other similar federation.

That degenerate case is really the one where you can make a plausible argument that metadata is as much hassle as help. When there's no key, not only does the information being exchanged reduce to very little, but it's much more static, and there's no key revocation problem.

> However, I am still new to Shibboleth, so I am thinking: maybe there
> _is_ some way to set up an SP in Shibboleth without corresponding
> metadata. Is there?

You can:

- turn on unverified request support and simply respond to any request with no checking (then you only need metadata for IdPs for signing/encryption)

- manually craft the metadata for the SP

- write a Java plugin to consume some other format and expose it via the MetadataResolver and EntityDescriptor/etc. APIs in the software

The latter is how you can conceptually support any kind of format you want, but in the end the data model is SAML metadata. The only extant example of somebody doing that is the CAS support in the IdP now, which mocks up metadata for expediency but doesn't require it for CAS services.

We have not defined a non-XML format as an alternative to the standard, as we don't think the benefits are worth the hassle and the confusion over which to use.

> If not, and they are simply expecting us to construct the metadata for
> them, I am interested in the opinion of others who run IdPs: do you
> construct metadata for these sorts of SPs?

All the time. Getting a static metadata file doesn't help me. If it's not signed and appropriately refreshable, then it does me no good anyway and in the end I'm going to have a metadata file directly loaded, so who creates it doesn't really matter much.
 
-- Scott