Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] Best practice to test new metadata

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] Best practice to test new metadata

Chronological Thread 
  • From: Ken Weiss <>
  • To: "" <>
  • Subject: Re: [Metadata-Support] Best practice to test new metadata
  • Date: Fri, 14 Feb 2014 18:31:59 +0000
  • Accept-language: en-US

Thanks Scott. That's a very clear and complete response. An unsatisfying
one, in that the message is that, given my situation, I really can't
pre-test fully, but clear and complete... :-)

Seriously, thanks very much for the time and effort you put into
supporting Shibboleth, and especially for responding to beginner questions
like mine.

Ken Weiss

UC Office of the President 510-587-6311 (office)
California Digital Library 916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612

On 2/14/14 10:02 AM, "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
>> and However, I
>>like to be able to test, and quickly roll back, the changes to our
>>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
>>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
>>could still log in. But this is clearly not the best way to proceed
>>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,
>>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
>You can't run only half of an SSO system and test fully. That's just the
>reality of the situation.
>-- Scott

Archive powered by MHonArc 2.6.16.

Top of Page