InCommon metadata support

[Ken Weiss <>]

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
------------------------------------------------------------
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" 
<>
 wrote:

>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
>
>