How does the InCommon 'preview' metadata aggregate work?

[Cantor, Scott]

On 2/13/14, 7:58 PM, "Ken Weiss" <ken.weiss at ucop.edu> wrote:

>Another in a long series of really, really simple questions, I'm
>afraid... RTFM is a totally valid response, if you can point me to the
>right FM - I've googled around for an hour or two without finding an
>answer. I think my question is so basic the answer hasn't been documented.

You probably should read this:

https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement

>Does an IDP get my SP's metadata from an InCommon metadata provider, or
>does the IDP get the metadata directly from my SP?

That's up to the IdP. A point of InCommon is to act as an aggregator and a
third party authority, because getting it directly from the SP is either
less secure, or presumes the trust relationship the metadata is supposed
to establish.

>I want to publish new metadata for my SP with InCommon. InCommon has
>three possible metadata aggregates - production, fallback, and preview. I
>would like to test my metadata before I push it into the production
>aggregate.

You don't need to test metadata by hiding it. If you need to stage
something, then you may need staging systems, or even a separate SP
registered, but that's not the same thing.

Once you publish metadata, you're committing to what it says, so anything
that has to be verified first needs to be done before you do that step. If
you have no IdP to use for that, testshib is one option. As one gets
experienced, the need to do a lot of that just goes away.

>It seems to be completely separate from SP metadata, so I'm inclined to
>guess that if I point my SP at the preview metadata and then attempt to
>log in using any of my federated IDPs, I'll be conducting a valid test.
>Is my guess correct?

The misunderstanding of the point of the preview aggregate aside, I think
you're not understanding how metadata flows. What you consume has nothing
whatsoever to do with your own metadata nor with how IdPs are getting
metadata about you or what that metadata would be. An SP only needs IdP
metadata and vice versa. IdPs get what you publish in InCommon or publish
some other way, but it has nothing to do with what you consume yourself.

As a procedural matter, the other point of federations like InCommon is
establishing expectations around metadata change. Systems following IC
federation guidelines will receive updates within a day of the published
change, but nothing sooner than that is to be assumed. The reality is that
some IdPs are running metadata-challenged software and won't get any
change no matter what. Part of operating a service is the expectations
around how it should behave in the face of that and who's problem it is
when IdPs break.

SPs that are open to adopt and don't operate on contracts typically have
to perform good error handling and force IdPs to bear the cost of
operating bad software and hurting their users. Contract/cloud services
are usually handled much more hands-on because outages aren't something
tolerated, and the benefit of multi-lateral federation are much more
limited for them.

Basically, something like carmenwiki.osu.edu is a fantasically simple app
to federate because it "just works" and any problems that occur are 100%
not our problem to fix. No warranty offered or implied. Something like
box.com is a pain to federate because the whole world does not run
Shibboleth and has no clue what operational stability in the face of
change means. It's a manual slog, and changing anything is a hugely
expensive job.

I don't know the specifics of your scenario, but understanding what you
have to do to make changes is unfortunately a major part of this, and it's
not a simple recipe to follow.

-- Scott, feeling loquacious