servicenow SAML 2 integration

[Liam Hoekenga]

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/..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140424/7ad02647/attachment.html