OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]