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.

Regards,

Bryan

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
>>of issues.
>> 
>> 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
>assertions.
>
>> 
>> 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
>such.
>
>> 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)
>attribute -->
>    <resolver:AttributeDefinition xsi:type="ad:Simple" id="mailNameID"
>sourceAttributeID="mail">	
>        <resolver:Dependency ref="myLDAP" />
>	<resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
>             
>nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
>	<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>             
>nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
>    </resolver:AttributeDefinition>
>
>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:PolicyRequirementRule
>xsi:type="basic:AttributeRequesterString"
>value="https://www.servicex.com/..."
>/>
>        <afp:AttributeRule attributeID="transientId">
>          <afp:DenyValueRule xsi:type="basic:ANY" />
>        </afp:AttributeRule>
>        <afp:AttributeRule attributeID="mailNameID">
>          <afp:PermitValueRule xsi:type="basic:ANY" />
>        </afp:AttributeRule>
>    </afp:AttributeFilterPolicy>
>
>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
>alternate NameID.
>
>> 
>> Thanks...
>> 
>> --
>> 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 mailing list