Firewall sample application and requirements

Why do firewalls break with SOAP being used as an application protocol?  My
guess is that you will say because the method name is inside the message.
And that parsing the message to get the method name does not scale.

So if I can (again) talk about requirements and scenarios (why is this so
hard?).  FWIW, I'm getting increasingly frustrated with vague and grandiose
claims that lack detail.  This is probably my last attempt to initiate a
meaningful discussion on the subject of SOAP vs Web architecture.

Sample Application: A StockQuote service has 2 different methods,
getStockQuote for retrieving a quote and a setStockQuote for setting the
price.  There are different security ACLs for each of the methods.

Requirements: An intermediary, typically a security intermediary such as a
firewall, should be able to determine the whether to allow or deny access
based upon the methods message in a timely manner.  Quote updates must have
higher priority than gets, as the information must be as current as possible
according to SLAs.

Design:

1. Using a SOAP HTTP POST binding to a single URI for both of these, a
security intermediary must scan the SOAP message to find the first child of
the body in order to determine which ACL to apply.  The time to scan thus
varies linearly with the number of headers.  In typical applications
however, there will be few headers.  The admin of the security intermediary
must know which SOAP method to configure the ACLs for.

2. Using HTTP GET and HTTP PUT for each of these, a security intermediary
can use the HTTP method to determine which ACL is applicable.  The admin
must know which HTTP method to configure the ACLs for.

3. Two different URIs are used with SOAP HTTP POST.  The security
intermediary applies the different ACLs to the different URIs, rather than
URI/method tuples.  The admin applies the ACL to any and all operations at
the URI.  We would probably partition the application in different clusters
for the prioritization.  Further, we'd probably do some kind of session
affinity for the "writes", as there is probably only one "writer" though
many readers.

In all cases, the intermediary scans the message for the security
credentials.

Benefits of each design:

1. The service could be deployed to additional protocols and the admin does
not have to know any additional method information, ie use the same
method/ACL binding for SMTP. Easier deployment - there's only 1 resource
that is deployed.

2. Scanning time to find method name.  Easier deployment - there's only 1
resource that is deployed.

3. Handles node scalability better as it's easier to cluster services by URI
than by method on a URI.  Also simpler for the admin to do security.  This
is also standard web practice today - higher security messages are typically
done using SSL on a completely different URI space and set of servers.
Further, because the method does not have to be determined, this is the
highest performant security model.  Finally, this model is more consistent
with current security firewalls which are typically at the URI level.  Most
web firewalls have a default mode that lumps GET and POST together into the
same ACL.  Firewalls do typically offer HTTP method distinction, but it's
not used as often as URI/any method style.

The choice of application design is dependent upon the trade-offs between
Service RAS (what #3 optimizes for), run-time performance (#2) and ease of
deployment across multiple protocols(#1).

Summary:
This sample application, requirements and designs provide no compelling
evidence that SOAP as an application protocol is broken.  While I'm
reluctant to bring Roy's thesis into the discussion, his thesis does
specifically talk about which functions REST is optimized for.  And that's
the level of what our discussions should be at.  Maybe web services
applications require different optimizations that browser applications.

Further, this example shows the notion and design of resources and
representations of resources are application specific.  The web certainly
optimized for certain types of resources (html pages, images) and
applications (browsers).  The optimizations may not be appropriate for
application to application communication such as stock quotes.

Finally, the alleged problem of having to look inside the message for the
method was solved in SOAP 1.1 with the HTTP SOAPAction Header.  If this was
such a crisis issue, why was this dropped from SOAP 1.2 and why isn't there
a number of people (like yourself) lying in the road requiring SOAPAction?

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Tuesday, May 28, 2002 4:41 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: SOAP and transfer/transport protocols
>
>
> On Mon, May 27, 2002 at 10:58:36PM -0400, Champion, Mike wrote:
> > OK, what requirements and usage scenarios are not met when SOAP
> > is treated as the application protocol, and HTTP is a transport
> > protocol rather than an application protocol?
>
> Off the top of my head;
>
> - inability to reuse established agreement that permits a priori
> communication
> - inability to work over firewalls in the long run
> - inability to properly leverage the value-add of intermediaries
> developed for that application protocol (such as firewalls)
>
> It is a complete non-starter for an Internet scale architecture to do
> what you and David are suggesting.  On the other hand, if you
> only want
> Web services to work behind the firewall, then this would be
> the easiest
> way to ensure that, because there's no pesky trust boundaries to worry
> about - i.e. you can safely assume a single administrator;
>
> http://java.sun.com/people/jag/Fallacies.html
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>
>

Received on Tuesday, 28 May 2002 17:53:40 UTC