ServiceNow "Multi-Provider SSO"

[Mark K. Miller]

On Thu, 26 Jun 2014, Paul B. Henson wrote:

> So evidently our ServiceNow environment has been updated to the release 
> including the new multi-provider SSO functionality as pioneered by CMU.

All actual experience shared by Michael overrides any story I'm about to 
tell...

> I was assuming this functionality would make things nice and simple like 
> many of our other shibboleth integrations for service providers 
> supporting InCommon; I was expecting that they would give me the 
> entityid of their SP in the incommon metadata, and I would release the 
> unique identifier attribute we want to use to join to the ServiceNow 
> database.

Me too!!!  I went round and round with them about this via email, until I 
finally got a very nice WebEx presentation about how it all works.

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?

With that in mind, the way I'm envisioning the ServiceNow 'puzzle' goes 
something like this.

You do the provisioning and setup of the ServiceNow app.  Some of that 
process is to include having it protected with an SP.  You get the 
metadata that describes that SP, and _YOU_ go register the metadata for 
your new SP with InCommon.

Once all that's done, you already mentioned that you know what to do with 
your IdP.

> However, the consultants they hired to do the ServiceNow side have been 
> spinning in circles and made no progress at getting it to work. I 
> started to dig through the documentation myself:
>
> http://wiki.servicenow.com/index.php?title=Multiple_Provider_Single_Sign-On
>
> On that page, to actually configure an SSO instance, it points you to:
>
> http://wiki.servicenow.com/index.php?title=SAML_2.0_Web_Browser_SSO_Profile#SAML_2.0_Setup
>
> Which seems to be the same hardcoded crap and kludgy custom nameid 
> attribute generation that we were looking at before the multi-provider 
> SSO implementation?
>
> Unless there are some other early adopters out there,

I'm not an early adopter, yet.  I'm pretty sure I will be within a few 
weeks, though.

>                                                       I'm guessing 
> there's only one person on this list who actually has this 
> working ;). Michael, could I trouble you to clarify how this is supposed 
> to work :)? Do we still need to hardcode ServiceNow metadata on the idp 
> side and provide them a custom nameid attribute? Going back to look at 
> your original email mentioning it, I see you said "Getting them to 
> publish into InCommon MD was a secondary concern", does that mean that 
> the new implementation should automatically know about our idp metadata 
> from the incommon feed, but we still need to maintain theirs in an ad 
> hoc fashion?

I hope the ideas I shared above actually apply as demonstrated in the 
WebEx I saw.  If so, the story in this last paragraph can be told a bit 
differently, and I think it'll be more acceptable to us all.

> Thanks...

I hope that helps!  You're welcome,

Max

> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst  |  henson at csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net