Issues Setting up SAML2 with ServiceNow

Cantor, Scott cantor.2 at osu.edu
Wed Mar 11 16:31:22 EDT 2015


> Can you elaborate on the difference (as it relates to Shiboleth) between
> encrypting the response vs signing the response?

Well, firstly you're confusing which end's key is involved. Keys in the metadata belong to the entity named by the metadata. A signing key for an SP has nothing to do with signing responses, it's for verifying signed requests or TLS connections to a SOAP port at the IdP. The encryption key for an SP is the key to which the content being encrypted by the IdP gets wrapped under (that's an oversimplification, but close enough), which is in the opposite direction (IdP to SP), and is the part at issue here.

> I have the following in my relying-party.xml:

You have a lot of extra unnecessary signing going on there, FWIW.

> From your comment, I'm assuming that the use="signing" restriction means
> that the key can only be used for signing the requests/assertions and not
> encrypting it.

It means the key is used to verify signed requests from an SP, but that's correct, it isn't used to encrypt data to it.

> I see above that I have encryptAssertions="conditional"
> (saml:SAML2ECPProfile). What determines this conditional behavior?

It's documented in the wiki, but for these purposes it's the same as setting it to always, the data's going through the browser so it will require encryption be used and fail if it can't do so.

> Can I just remove the "signing" restriction?

That depends entirely on the SP. You can't make an SP support encryption if it doesn't, and you can't make it use any given key you want it to use. The metadata comes from the SP's capability and configuration of keys, not the other way around.

FWIW, I don't believe Service-Now supported encryption when we configured it, but I don't know if that's still true.

-- Scott



More information about the users mailing list