RE: [saml-dev] Query regarding SAML specification and SSL

["Scott Cantor" <cantor.2@osu.edu>]

Darshan Karandikar wrote on 2009-07-31:
> [Darshan]: Are you saying that the web server should ensure that the
scheme
> and port in HTTP request header "stays" as "SSL" even though the actual
> scheme when the request reaches web server in the stated environment is
HTTP
> (since SSL accelerator has done the SSL processing and forwarded the HTTP
> request to web server).

Yes, that's a requirement any time you virtualize. Correctly written
applications rely on the web server to tell them what the incoming request
looks like in order to generate redirects and self-referential URLs. They
have to match what the browser sees, not what the server physically sees.
None of this has anything to do with SAML.

> And if this is done on web server, then what's the point in validating
> "https://"; in SAML implementation when we know the incoming request is
> always going to carry "https://"; because the web server itself is going to
> set the request scheme to "SSL" for every incoming request.

The point is to move complexity out of the SAML implementation and give it
as easy a job as possible. Making security code more convoluted than
necessary isn't a good thing. The comparison should be direct without any
special effort.

> I feel it will
> be more logical to leave the SAML implementation "configurable" to select
> either "http://"; or "https://"; check (instead of enforcing "https://";
check
> always) based on the environment under consideration. The SAML
administrator
> has to be clever enough to select whichever option that is good enough to
> ensure prevention of MITM attack in given environment.

I don't think it's logical to treat SAML differently than any other
application code on the server. The web server needs to do the right thing
for all the services it's hosting, or they will either generate redirects
incorrectly or be will be hardcoding URLs all over the place, which is just
bad design.

Not to mention that if you change the comparison rules, you still have to go
back and somehow make it generate redirects back to itself properly, and
those are backwards from what you're describing, they have to be https, not
http. Why not do it properly and configure the web server correctly in the
first place?

SAML implementations that have to support web servers like IIS that don't
support SSL virtualization have to compensate for this kind of thing, but
the compensation should be outside the mainline SAML processing logic so
that it doesn't need to care.

None of this is dictated by the standard. How you implement it is up to you.

-- Scott