servicenow SAML 2 integration

[Cantor, Scott]

On 4/23/14, 7:37 PM, "Paul B. Henson" <henson at csupomona.edu> wrote:

>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?

No, they don't do XML Encryption. They use a one-off implementation they
created based on OpenSAML (the Java version), and it is substantially
better than it was, but it's not Shibboleth certainly, there are massive
deficiencies as with most one-offs.

>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?

It's still required. Conditional doesn't mean "if they have a key", it
means if there's no confidential channel end to end.

>Evidently they require a NameID format attribute to join to their
>internal database.

Well, they require a NameID, yes. I don't believe they look at the Format,
but I don't recall offhand.

> 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?

Yes.

> I also read in an older posting that you need to hack the default
>releaseTransientIdToAnyone policy to explicitly exclude them, is that
>still true?

No, there are many knobs. You can use a NameID format precedence set in
the RelyingParty, or you can just include a NameIDFormat element in the
metadata you cook up for their service and give to your IdP that includes
the right format. The wiki documents how format selection works now.

-- Scott