on-prem application

[Lohr, Donald]

So for a quick interpretation:

If a on-prem (local hosted) application (which points to our only IdP) 
is completely developed or managed by someone that works for our 
organization, there is no point in having it's metadata joined with 
InCommon's metadata.

If a on-prem (local hosted) application (which points to our only IdP) 
is developed, installed and mostly managed by the vendor, there is 
advantage in having it's metadata joined with InCommon's metadata.

At this point I do not understand the "key change" reference.  If you 
would be so kind as to provide a bit more information on what that means.

Thanks so very much for all you do,
DL

On 3/20/19 6:10 PM, Cantor, Scott wrote:
> On 3/20/19, 5:56 PM, "users on behalf of Peter Schober" <users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:
>
>> Having to perform key rollover for your IDP with InCommon *and*
>> *again* with every such SP manually or risk complete breakage?
> Everything on and off campus is divided into "compliant" and "broken" typically, so you have your local metadata feed serving the working systems and everything else is broken anyway.
>
> As I am discovering myself in working through my key change, the key (pun intended) is to capture, document, and tag all the broken systems so that they can be identified later and locked on to the old or new key as needed, while everything else is managed with a normal metadata change.
>
> Then you make sure management understands that changing keys annually is unworkable, and document the process as a "if we have to" contingency.
>
> But no, having some on-campus system I'm managing or we have staff managing going into InCommon's metadata is a pointless exercise. If it's not federated, it doesn't belong there unless it's operated by somebody that's not part of my organization.
>
> I think all the campuses that have tried to leverage InCommon for their non-federated systems have generally regretted it at worst, or found it pointless at best, but I suppose it depends on how comfortable with scripting metadata generation one is.
>
> -- Scott
>
>