ServiceNow "Multi-Provider SSO"

[Eric Goodman]

Mark K. Miller [max at psu.edu] said:
>Consider that 'the cloud,' and specifically provisioning your own services 
>in 'the cloud,' shakes up our familiar federation model a bit.  While you 
>still could think that there's an SP that belongs to ServiceNow, that's not 
>what they think.  Their view, and I feel it's a perfectly acceptable one, 
>is that what you provision in their cloud belongs to you.  The even more
>generic case, of course, is AWS.  You'd never expect AWS to be an InCommon 
>member to be able to have an SP in front of applications you've provisioned 
>there, would you?

Simplistically, you can argue that "who registers" the SP maps to whether the deployed application's URL is service.myvendor.com vs service.mycampus.edu. I agree that actually registering the metadata to InCommon could be done under either the vendor's or my institution's membership, so long as the entityID registered is only used for applications in the registerer's scope of control.

But that's different than the discussion of how the SP is provisioned and managed.

Taking your AWS example slightly differently: AWS as a PaaS vendor, I agree, SP configuration is all me. However, IIRC AWS allows federating the logins to the AWS control dashboard (that allows provisioning instances, etc). That instance of the SP is an AWS-provided service. 

I think the key is requirement on the set of technical capabilities of the vendor-provisioned SPs, because the SP functionality is part of the vendor service. Where that's the case, I still want all of the requirements Michael spelled: ability to generate and consume metadata, ability to talk to multiple IdPs (because my University has multiple IdPs), etc.


I'm not sure whether my comments are agreeing with, disagreeing with or modifying yours, but I wanted to clarify the "registering" vs. functionality part regardless. :)

--- Eric