servicenow SAML 2 integration

Tom Scavo trscavo at
Wed Apr 23 20:21:01 EDT 2014

On Wed, Apr 23, 2014 at 7:37 PM, Paul B. Henson <henson at> wrote:
> They want to exchange metadata in an ad hoc fashion, rather than availing of Incommon (always annoying)

FWIW, they have published metadata in InCommon (although it doesn't
look production metadata).

> but the metadata they supply does not include a certificate?

Presumably because their software doesn't support XML Encryption?
(Looks like they're using OpenAM.)

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

Well, the IdP only sends responses to trusted endpoints, so as long as
they maintain control of the endpoint, you're fine. XML Encryption
requires them to maintain control of the decryption key as well, which
is better.

Most federations (InCommon included) require every SP in metadata to
have an encryption certificate. Of course if the SP can't deal with
encryption, that leads to one-off hacks like this one. We've discussed
relaxing the encryption requirement in situations like this (but
haven't actually taken the plunge). The rationale is it's probably
better for such SPs to be in metadata even if they can't/won't support
encryption. It's a trade-off.


More information about the users mailing list