* Jethro R Binks <[log in to unmask]> [2009-12-09 17:46]:
> > Login was via Shibboleth/SAML and over SSL (you still want an SSL-cert
> > on that service, so those HTTP POST requests from an IdP that carry the
> > SAML assertion still end up at HTTPS endpoints -- otherwise browsers
> > will complain), but the rest was accessed via plain HTTP (using an HTTP
> > cookie that's not flagged 'secure', obviously).
>
> And is this, generally, a concern?
[...]
> It wouldn't be hard to shibbolize this service and add to our local
> federation, so that non-campus clients get authenticated via the IdP
> instead, but of course, this website is still delivering over HTTP rather
> than HTTPS. I'm happy the authentication is protected, less sure about
> the potential consequences for the cookie content.
The security of the cookie is one thing, but the point I was trying to
make is this: Unless the vhost for an SP is SSL-enabled and /only/ the
SSL-ified endpoints are used for SAML/Shibboleth, in usual
deployments[1] all common HTTP user agents will intercept the HTTP
POST with a security warning (because the POST originates from HTTPS
-- your IdP better be SSL-protected -- and ends up on plain HTTP).
Stupid thing is, because the webbrowser does not look inside the POST
body, it cannot know that with SAML2 the form content will probably
be encrypted with the public key of the recieving SP anyway (likewise
with SAML1.1, there will be nothing of interest in the POST because
the SP requests attributes directly from the IdP) and hence it's
actually perfectly safe to transmit things over plain HTTP.
So the warning might very probably be bogus, but it's still there.
So unless you're prepared to tell users it's OK to click way /those/
security warnings (only those of course, as if anyone could tell the
difference...), you'll want SSL-protection for all Service Providers
(at least for their SAML-endpoints, if not the whole vhost).
cheers,
-peter
[1] I.e. the HTTP POST binding is used to transfer the SAML
authentication assertion from the IdP to the SP via the HTTP user
agent. (This does not apply to HTTP Artifact binding, since only
GET requests are involved there.)
--
[log in to unmask] - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
|