Response to AttributeQuery is not signed

[Roman CHRENKO]

Hello.

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. (Encryption is no such issue in our case.)

And now back to my question.
I wrote in my first email that we have configured profileConfiguration  (we set signResponses="true" in our profileConfiguration) as you can see below.
And you wrote "set the signResponses profile configuration setting for that profile".
But we did it. And without success.
Do you mean any other profile configuration? Where it is? Why isn't our profile configuration sufficient?

As I wrote in my first email, my configuration in relying-party.xml is:
        <bean parent="RelyingPartyByName" c:relyingPartyIds="http://fedora22.rch.org/shibbolethSP">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="false" p:signResponses="true" p:skipEndpointValidationWhenSigned="true" />
                    ...
                    <ref bean="SAML2.AttributeQuery" />
                    ...
                </list>
            </property>
        </bean>

Roman


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, September 16, 2016 3:25 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Response to AttributeQuery is not signed

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

> Can you, please, suggest me, how to configure IDP to sign responses to AttributeQuery?

Not use TLS, or set the signResponses profile configuration setting for that profile. Signing is silly if TLS is used, and most uses of Shibboleth involve TLS with a self-signed certificate today, though that's something we'd like to change (well, not really, but it's necessary).

Message level security is a very poor substitute for TLS, but that's where things are headed, to the extent queries even remain relevant (they're mostly not anymore).

-- Scott


-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net