How to support an SP that accepts both http and https on IdP

[Yaowen Tu]

Nate,

Thanks a lot for you answers. For some reasons, we have to support http for
some SP at the beginning, but we will suggest our user to support https
ASAP.

Just to double check, are you saying that in the metadata we can list
something like:

<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="
http://localhost/SSO/SAML/ACS/Post" index="0"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https:/localhost/SSO/SAML/ACS/Post" index="1"/>

And in each individual AuthnRequest,SP can decide which one to include in
the request, and expect the IdP to respond to it, right?

Thanks,
Yaowen


On Tue, Mar 26, 2013 at 2:13 PM, Nate Klingenstein <ndk at internet2.edu>wrote:

>  I should probably strengthen this language.  Specifically, user
> authentication is often done via password.  In this case, you're not just
> concerned with an attacker being able to take over a bearer token or a
> session; it's something more persistent and less tied to an instance, and
> it can generally be played by the attacker to the IdP at any time.
>
>  On Mar 26, 2013, at 21:07 , Nate Klingenstein wrote:
>
> Similarly, I would recommend that the IdP listen only over TLS.  If your
> metadata reflects this, then users should never be showing up at your IdP
> on port 80 anyway. Whether or not to redirect users that arrive on port 80
> for some reason to 443 is up to your discretion.
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130326/c8ae9964/attachment.html