servicenow SAML 2 integration
Bryan E. Wooten
bryan.wooten at utah.edu
Wed Apr 23 22:13:14 EDT 2014
We are currently deploying Servicenow and it is protected by our Shib IDP.
I don't recall any special issues doing the integration. I would be happy
to share any configuration files.
This may take us a week or 2 to put together as our Shib expert is on
vacation through next week.
Feel free to contact me off list.
On 4/23/14 7:31 PM, "Michael A Grady" <mgrady at unicon.net> wrote:
>On Apr 23, 2014, at 6:37 PM, Paul B. Henson wrote:
>> I've been asked to integrate our shibboleth idp with servicenow. I've
>>seen a few postings regarding this, but would like to clarify a couple
>> They want to exchange metadata in an ad hoc fashion, rather than
>>availing of Incommon (always annoying), but the metadata they supply
>>does not include a certificate? They do consume a certificate from my
>>idp metadata, so can presumably verify the assertions it provides, but
>>with no certificate for their SP, how does the idp verify a request is
>>actually coming from them and not some random imposter?
>Tom already answered that, the metadata identifies the endpoint. And at
>least they gave you metadata, for a number of vendors you need to
>hand-craft the SAML metadata for them. (Pretty easy, but yet another
>step.) There are a number of vendors who cannot handle encrypted
>> One of the integration guides I was looking at said it required a
>>custom RelyingParty configuration in relying-party.xml so the idp would
>>not try to encrypt assertions; the example config included
>>encryptAssertions="never". However, my current default relying party is
>>configured with encryptAssertions="conditional", is a separate relying
>>party with an explicit never still required or was that for an older
>>version of the idp?
> encryptAssertions="conditional" means encrypt if there isn't something
>else providing confidentiality between the sender and the intended
>recipient. And in the standard SAMLv2 POST flow the message is sent to
>the user agent, and then from there to the intended recipient, so there
>isn't anything else providing that confidentiality -- i.e.
>encryptAssertions="conditional" essentially means 'always' with the
>SAMLv2 POST flow. So you do need to add a special relying party config
>with encryptAssertions="never". And not that it usually breaks anything,
>but some of these SPs actually don't take any attributes, they just use
>the NameID. So you could also add 'includeAttributeStatement="false"' for
>> Evidently they require a NameID format attribute to join to their
>>internal database. Our current configuration only supplies the
>>transientId and eduPersonTargetedID with such an encoding, neither of
>>which is suitable, so it seems a new special attribute must be defined
>>specifically for servicenow that encodes one of our other existing
>>attributes in NameID format? I also read in an older posting that you
>>need to hack the default releaseTransientIdToAnyone policy to explicitly
>>exclude them, is that still true?
>Yes, you'd have something like the following example that you'd add to
>your attribute resolver:
> <!-- Generate a SAML email-type NameID from the mail (email)
> <resolver:AttributeDefinition xsi:type="ad:Simple" id="mailNameID"
> <resolver:Dependency ref="myLDAP" />
> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>And then, in the attribute filter, something like:
> Release the email address of the user, as the NameID, to Service X
> <afp:AttributeFilterPolicy id="Service X">
> <afp:AttributeRule attributeID="transientId">
> <afp:DenyValueRule xsi:type="basic:ANY" />
> <afp:AttributeRule attributeID="mailNameID">
> <afp:PermitValueRule xsi:type="basic:ANY" />
>You don't need to mess with the global "release transientID to anyone"
>config, just add the Deny for it for those SPs where you need to send an
>> 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
>Michael A. Grady
>Senior IAM Consultant, Unicon, Inc.
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
More information about the users