saml-dev message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [saml-dev] Query regarding SAML specification and SSL
- From: Darshan Karandikar <darshan.karandikar@tcs.com>
- To: "Scott Cantor" <cantor.2@osu.edu>,saml-dev@lists.oasis-open.org
- Date: Tue, 4 Aug 2009 17:06:43 +0530
Thanks for the explanation.
One query regarding the SAML implementation:
Consider following path a HTTP request
follows in a typical large enterprise setup:
Web browser --> hardware load balancer
--> hardware SSL accelerator --> web server --> DMZ inner firewall
--> application server.
Path from web browser to SSL accelerator
is SSL enabled.
Assume SAML is used in this setup to
do web SSO (Browser/POST profile) between 2 of the applications within
the enterprise. In order to protect against MITM attack on SAML token in
this setup, which of the following option is "practical":
1) Terminate SSL processing on h/w SSL
accelerator and rest of the path from SSL accelerator to application server
uses HTTP? OR
2) Use SSL even between SSL accelerator
& web server as well as between web server & application server?
If there are a number of web and application servers hosting hundreds of
applications (which is the case with large enterprises), it will be an
overhead, performance as well as private key management point of view (too
many web & application servers need to have private key in keystore
+ any new server has to ensure it has the key), to implement SSL between
each of the components in the path. Also, you will lose the benefit of
having a h/w SSL accelerator in first place i.e. performance improvement.
I feel option 1) is better and more
practical because-
1) All the SSL management is consolidated
on h/w SSL accelerator, which is designed for the same.
2) The path between SSL accelerator
to application server, being non-SSL, improves performance without compromising
SAML token security. This is because that path lies "inside"
the enterprise network which is trusted, and hence free of MITM attack
risk on SAML token.
Is there any "SAML best practice"
regarding this?
Please let me know your opinion.
Regards,
Darshan.
"Scott Cantor"
<cantor.2@osu.edu>
07/31/2009 11:22 PM
|
To
| "'Darshan Karandikar'" <darshan.karandikar@tcs.com>,
<saml-dev@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [saml-dev] Query regarding SAML
specification and SSL |
|
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
ForwardSourceID:NT000148F2
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]