Metadata, examples, best practices?

[Cantor, Scott]

On 11/27/13, 2:33 PM, "Jason Gauthier" <jgauthier at lastar.com> wrote:

>I have used shib a few times, and achieved what I wanted to achieve.  I
>am now setting up something a little more elaborate and I want to get
>things done well from the beginning.
>For my environment shib is an SP, and ADFS is the IDP.  Just to set the
>imagery properly.

You have to understand that ADFS is not a fully metadata-capable product,
so you're talking about a system in which many of the answers to your
questions would result in a non-working metadata file. There's "best
practice" and there's "what ADFS can handle".

(You actually found one of those bugs already, the limitation on sharing
keys, which is a very major limitation. It misunderstands that the entire
point of using metadata for trust is to break the single key per entity
assumption. But I should note that you mentioned wildcards. You should
never use a commercial TLS certificate for SAML purposes, ever. That model
is very flawed and you will regret it endlessly.)

>In ADFS I could go the route of one relaying party with multiple
>assertion consumer endpoints, or I could make one for each "virtualhost".
>If I make one (maybe that's bad practice) how do I go about adding
>additional "md:AssertionConsumerService" records to the metadata?
>I attempted to do this, and it came out poorly.

I'd probably need to know what you mean to answer that. The metadata is an
XML file, you can cut and paste quite easily. You can also use scripts to
generate the metadata fairly easily, one of which is in the SP (but it's a
shell script for Linux).

And lastly, if you really want to go through the hassle, you can add all
sorts of XML to the Metadata handler in the SP to get it to auto-generate
multiple vhost endpoints.

>What is the preferred method to provide this metadata to ADFS? ( which is
>my only partner, and it's internal)

Well, the preferred method is with a third party federation. If you
honestly have one partner, then that's not a routine scenario we're trying
to talk about. With one partner, you can exchange the metadata out of band
and just communicate when there are changes to it. That doesn't scale and
that's what the comment is partly talking about.

>Is that simply copying what is generated automatically and then modifying
>it for my needs, and then servicing it up as on another URL, or is there
>any configuration where serving it up from the "generation handler" valid?

If your goal is to host the metadata yourself, then yes, the right model
is to separate the metadata you provide from anything generated. Typically
be indirecting lookup of metadata via the entityID, which can be
redirected to the generator if you really know what you're doing, but then
redirected to something else when necessary.

You cannot use metadata properly for things like key rollover if you tie
the metadata in real time to the exact configuration of the SP. Under no
circumstances should any IdP be accessing /Shibboleth.sso/Metadata. That's
the point of the comment.

There are also many kinds of extensions used in Shibboleth based
federations that can't be generated.

But to the immediate point, ADFS cannot safely be pointed to remote
metadata. That model doesn't work because ADFS can't secure that update
properly. ADFS is only safe to use with metadata exchanged out of band.

-- Scott