We've deployed it too. I can share configuration.<div><br></div><div>Liam<span></span><br><br>On Wednesday, April 23, 2014, Bryan E. Wooten <<a href="mailto:bryan.wooten@utah.edu">bryan.wooten@utah.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are currently deploying Servicenow and it is protected by our Shib IDP.<br>
<br>
I don't recall any special issues doing the integration. I would be happy<br>
to share any configuration files.<br>
<br>
This may take us a week or 2 to put together as our Shib expert is on<br>
vacation through next week.<br>
<br>
Feel free to contact me off list.<br>
<br>
Regards,<br>
<br>
Bryan<br>
<br>
On 4/23/14 7:31 PM, "Michael A Grady" <<a>mgrady@unicon.net</a>> wrote:<br>
<br>
><br>
>On Apr 23, 2014, at 6:37 PM, Paul B. Henson wrote:<br>
><br>
>> I've been asked to integrate our shibboleth idp with servicenow. I've<br>
>>seen a few postings regarding this, but would like to clarify a couple<br>
>>of issues.<br>
>><br>
>> They want to exchange metadata in an ad hoc fashion, rather than<br>
>>availing of Incommon (always annoying), but the metadata they supply<br>
>>does not include a certificate? They do consume a certificate from my<br>
>>idp metadata, so can presumably verify the assertions it provides, but<br>
>>with no certificate for their SP, how does the idp verify a request is<br>
>>actually coming from them and not some random imposter?<br>
><br>
>Tom already answered that, the metadata identifies the endpoint. And at<br>
>least they gave you metadata, for a number of vendors you need to<br>
>hand-craft the SAML metadata for them. (Pretty easy, but yet another<br>
>step.) There are a number of vendors who cannot handle encrypted<br>
>assertions.<br>
><br>
>><br>
>> One of the integration guides I was looking at said it required a<br>
>>custom RelyingParty configuration in relying-party.xml so the idp would<br>
>>not try to encrypt assertions; the example config included<br>
>>encryptAssertions="never". However, my current default relying party is<br>
>>configured with encryptAssertions="conditional", is a separate relying<br>
>>party with an explicit never still required or was that for an older<br>
>>version of the idp?<br>
>><br>
><br>
> encryptAssertions="conditional" means encrypt if there isn't something<br>
>else providing confidentiality between the sender and the intended<br>
>recipient. And in the standard SAMLv2 POST flow the message is sent to<br>
>the user agent, and then from there to the intended recipient, so there<br>
>isn't anything else providing that confidentiality -- i.e.<br>
>encryptAssertions="conditional" essentially means 'always' with the<br>
>SAMLv2 POST flow. So you do need to add a special relying party config<br>
>with encryptAssertions="never". And not that it usually breaks anything,<br>
>but some of these SPs actually don't take any attributes, they just use<br>
>the NameID. So you could also add 'includeAttributeStatement="false"' for<br>
>such.<br>
><br>
>> Evidently they require a NameID format attribute to join to their<br>
>>internal database. Our current configuration only supplies the<br>
>>transientId and eduPersonTargetedID with such an encoding, neither of<br>
>>which is suitable, so it seems a new special attribute must be defined<br>
>>specifically for servicenow that encodes one of our other existing<br>
>>attributes in NameID format? I also read in an older posting that you<br>
>>need to hack the default releaseTransientIdToAnyone policy to explicitly<br>
>>exclude them, is that still true?<br>
><br>
>Yes, you'd have something like the following example that you'd add to<br>
>your attribute resolver:<br>
><br>
> <!-- Generate a SAML email-type NameID from the mail (email)<br>
>attribute --><br>
> <resolver:AttributeDefinition xsi:type="ad:Simple" id="mailNameID"<br>
>sourceAttributeID="mail"><br>
> <resolver:Dependency ref="myLDAP" /><br>
> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"<br>
><br>
>nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/><br>
> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"<br>
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder"<br>
><br>
>nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /><br>
> </resolver:AttributeDefinition><br>
><br>
>And then, in the attribute filter, something like:<br>
><br>
> <!--<br>
> Release the email address of the user, as the NameID, to Service X<br>
> --><br>
> <afp:AttributeFilterPolicy id="Service X"><br>
> <afp:PolicyRequirementRule<br>
>xsi:type="basic:AttributeRequesterString"<br>
>value="<a href="https://www.servicex.com/.." target="_blank">https://www.servicex.com/..</a></blockquote></div>