"override" of InC SP metadata?

[Christopher Bongaarts]

Just don't forget to remove it once the InCommon metadata has been 
corrected, or Future You will be scratching their head wondering why 
these blasted changes aren't taking effect.  :)

On 6/15/2019 10:26 PM, db at alaska.edu wrote:
> This worked for me. Thank you.
>
> David.Bantz at Alaska.edu
>
>
> On Jun 15, 2019, at 05:34, Michael A Grady <mgrady at unicon.net 
> <mailto:mgrady at unicon.net>> wrote:
>
>> Yes, just ran into that with another cloud vendor who has metadata in 
>> InCommon that is inaccurate (for the specific client) for the moment, 
>> and indeed just ordered a local "fixed copy" in 
>> metadata-providers.xml before the InCommon config. And that is working.
>>
>>> On Jun 14, 2019, at 10:18 PM, Nate Klingenstein <ndk at signet.id 
>>> <mailto:ndk at signet.id>> wrote:
>>>
>>> David,
>>>
>>> So far as I'm aware, it's first match wins.  If you write 
>>> replacement metadata and place an XML MetadataProvider prior to the 
>>> InCommon metadata provider that you're using, it should pick it up 
>>> preferentially.
>>>
>>> Take care,
>>> Nate.
>>
>> --
>> Michael A. Grady
>> IAM Architect, Unicon, Inc.
>>
>>
>>
>> -- 
>> For Consortium Member technical support, see 
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to 
>> users-unsubscribe at shibboleth.net 
>> <mailto:users-unsubscribe at shibboleth.net>
>
-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190617/361ee2fc/attachment.html>