[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: Shibboleth IdP v3 + Require signed Authnrequests
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2015-06-30 21:55:17
Message-ID: 663AB6FB-08FF-4932-B91E-5F2E5FA13B50 () osu ! edu
[Download RAW message or body]

On 6/30/15, 3:22 PM, "users on behalf of keijo.korte@kvak.net" \
<users-bounces@shibboleth.net on behalf of keijo.korte@kvak.net> wrote:

> We have forced signed requests with this kind of configuration. Of
> course there is a drawbacks (unsolicited), but it works.

I don't understand how it "works" if it's trivially circumvented, so I'm still not \
getting the point.

> Added below lines to the "<security:SecurityPolicy 
> id="shibboleth.SAML2SSOSecurityPolicy .." block in relying-party.xml:

The only line relevant there should be this one:

> <security:Rule xsi:type="security:MandatoryMessageAuthentication"/>

But that's what I figured you meant.

That's the only way to do it now, yes. There is no documentation on it. It involves \
modifying system files or creating a copy of the existing files and understanding a \
lot of low level details. I believe I ran through a similar explanation when ScottK \
asked about turning *off* authentication for Logout, so it's in the archives. I could \
add a property similarly to the one I did for that use case to toggle on a \
requirement to sign the requests.

> We are creating a proxy implementation and basically want to make sure 
> that we don't process unsigned requests. All of our requests are 
> initialized at SP, so thats why I am not so worried about unsolicited 
> requests.

That isn't true. You don't control where requests are initiated when you support \
unsolicited requests.

-- Scott

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


[prev in list] [next in list] [prev in thread] [next in thread]