InCommon metadata support

["Cantor, Scott" <>]

On 2/14/14, 12:05 PM, 
""
 
<>
 wrote:

>I have already made similar changes and tested by editing the production
>metadata for our development and staging environments - entityIDs
>https://dmp-dev.cdlib.org and https://dmp-stage.cdlib.org. However, I
>would
>like to be able to test, and quickly roll back, the changes to our
>production
>metadata somewhere other than the actual production environment.

The only way you can have control is with an IdP you control. In a
decoupled system, you can't do this kind of thing when others are involved.

>My initial thought was that I would put the new metadata into the preview
>aggregate, modify my SP to use the preview metadata provider, and see if I
>could still log in. But this is clearly not the best way to proceed
>because
>it's not what the preview aggregate is intended to do, and I'm not sure
>if the
>IDPs would even see the new metadata.

All the metadata aggregates will include your change. The preview
aggregate is about changes the federation makes to the metadata, not
changes you make.

>What is the recommended approach to testing, and quickly rolling back,
>changes
>to production metadata?

Honestly, it's "understand what every change to it will do". There is
nothing else that works other than operating your own IdP to test anything
you want.

Primarily, you don't change anything in place, you add things to the
metadata to accomodate new things, and then remove things that are no
longer needed later. For an SP, that's 90% of the changes you make. An SP
drives the flow, which means adding endpoints hurts nothing unless you ask
for a response to one that doesn't exist. Adding new ones has no effect on
old ones.

Even some of the larger changes an SP can make are generally not capable
of breaking existing relationships unless content is removed, with key
changes being the notable exception.

> Where should I install the modified SP metadata? How
>do I get at least one IDP to read that modified metadata and confirm that
>everything works as expected? Is this a job for testshib?

It's a job for an IdP that isn't operated by somebody else. Testshib is
operated by "everybody" in that sense, so lacking anything else, you can
use it, but you cannot control what testshib really does and what it
supports. It will test only the behaviors it's configured to actually
exercise.

You can't run only half of an SSO system and test fully. That's just the
reality of the situation.

-- Scott