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

Darshan Karandikar wrote on 2009-08-04:
> 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
> SSL accelerator to application server uses HTTP? OR
> 2) Use SSL even between SSL accelerator & web server as well as between
> server & application server?

Both are practical, I would imagine.

> 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
> SSL accelerator in first place i.e. performance improvement.

I think all that is overblown as a concern in most cases, but it's not
really up to me. I will simply point out that SSO *requires* hosting code
and usually implementing some form of key or shared secret on *every* web
server accessed by a client. Nothing you do will change that. You can deploy
it any way you want to, and you can use SAML only on one or some of those
systems and gateway to something else for the rest, but you CANNOT avoid
touching every accessible server in some fashion. Either they're running
authentication code or their proxied to.
> 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,
> hence free of MITM attack risk on SAML token.

I have never seen an enterprise network that deserved the kind of special
status you're giving it. Attacks come from insiders just as much as
> Is there any "SAML best practice" regarding this?


-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]