servicenow SAML 2 integration

[Chuck Kimber]

To those who said they could share their config, I would be interested in
that.  Our Shibb deployment initially worked with ServiceNow, then
something changed somewhere and it's been throwing metadata errors ever
since.


On Thu, Apr 24, 2014 at 6:41 AM, Liam Hoekenga <liamr at umich.edu> wrote:

> We've deployed it too. I can share configuration.
>
> Liam
>
>
> On Wednesday, April 23, 2014, Bryan E. Wooten <bryan.wooten at utah.edu>
> wrote:
>
>> 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/..
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140508/abbe1eb8/attachment.html