Response to AttributeQuery is not signed

Cantor, Scott cantor.2 at osu.edu
Fri Sep 16 10:42:18 EDT 2016


On 9/16/16, 10:34 AM, "users on behalf of Roman CHRENKO" <users-bounces at shibboleth.net on behalf of Roman_CHRENKO at tempest.sk> wrote:

> In our architecture the Attribute Authority (IDP) is behind the reverse proxy. TLS is
> terminated on this proxy. Also in the case new TLS is established between proxy and AA
> there is a security risk of message manipulation. We cannot guarantee end-to-end security
> (message authenticity). This is the reason why we would like to sign AA responses. 

Well, signing is about the recipient's security, not yours. If the client trusts the certificate on the proxy, then there's no issue. This is in fact the entire basis of the web's view of security, OpenID, etc. They do not generally sign, and they absolutely assume that whereever you terminate TLS, that's what you get.

The reverse is not true, obviously. Client TLS is impossible to do in most cases when you offload TLS, and so it's really request signing that is going to be the bigger deal.

But that background aside...

> I wrote in my first email that we have configured profileConfiguration  (we set
> signResponses="true" in our profileConfiguration) as you can see below.

Configuring the SSO profile has nothing to do with attribute queries.

 <ref bean="SAML2.AttributeQuery" />

No settings. Default is "sign if the connection is http or is https over port 443".

-- Scott
 



More information about the users mailing list