HTTP-only ACS URL

[Chad La Joie]

Paul, I believe you're right.  The only thing I could think of doing
that would enable this (but should scare your users) is to server up
the login page via HTTP but adjust the login page to submit to HTTPS.
That would, I think, keep the credentials secure but prevent the
browser from issuing that warning.  However it won't show the page as
secure and so, as I said, users *should* complain.

On Tue, Aug 2, 2011 at 15:45, Paul Hethmon
<paul.hethmon at clareitysecurity.com> wrote:
> Russ,
>
> My understanding of this is that it is dependent on browser. Some browsers
> will pop up that warning on the POST of data from the SSL site to the HTTP
> site and some don't. To add to that, some allow you to turn off the
> warning via preferences. To my knowledge there is not a way for the IdP
> site to control that behavior.
>
> I suppose, though have never tried, that if you used artifact binding, you
> might get around it. The redirect would be a simple GET and I don't think
> would trigger the warning.
>
> Paul
>
>
> On 8/2/11 2:31 PM, "Russell Beall" <beall at usc.edu> wrote:
>
>>I seem to be missing on my internet searches for how to set up an SP with
>>a non-HTTPS ACS URL.
>>
>>We have one working, but the browser complains bitterly on sending a POST
>>to an unencrypted location.
>>
>>Is there a different ACS Binding I should use, or some documentation
>>which describes this type of setup?  Or is this something to do just
>>during testing phases and isn't really for production release?  I was
>>intending to rely on the SAML2 application level encryption to secure the
>>data in transit...
>>
>>Thanks,
>>Russ.
>>--
>>To unsubscribe from this list send an email to
>>users-unsubscribe at shibboleth.net
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered