servicenow SAML 2 integration

[Michael A Grady]

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.