Alzo Spracht Mark Curphey:

> Does anyone know much about the security of this ?
>
> http://www-106.ibm.com/developerworks/webservices/library/ws-phtt/?dwzone=we
> bservices
>

<rant>
In a previous life, I was the manager of Secure Product Development Group at
the Visigenic division of Borland / Inprise. While many people criticize
CORBA for being a heavy-weight monstrosity (and in some respects it is,)
IIOP remains a viable protocol for most middleware configurations. While I
am not the worlds largest IIOP or CORBA fan, it did seem to work, and with a
little bit of tweaking, work well. N-Tier models like the one in the httpr
description are handled very well by protocols like IIOP passing Object
Requests.

From the looks of it, the guys who are specifying HTTPR are ignoring all but
the most basic security concerns. It appears that their idea of security is,
"just do httpr over ssl." Clearly they have never had to design a real
system. In the real world, we have lots of different partners at different
levels of the value chain; information moves from end entity to gateway to
application to database.

In the httpr model, each tier in transaction chain is responsible for it's
own end entity authentication, session cipher negotiation, and secure
storage of messages in transit. The only mention of security in the spec or
message board is a paragraph that says, "you're on your own."

As nasty and blobular as CORBASec is, at least you could specify delegation
requirements in an interoperable manner. There was also a non-standard
standard that described how to specify secure storage of object requests in
transit, and it was interoperable between at least two implementations.

This may seem like nothing much, but it did allow us to relatively easily
specify and implement a system like:

Handset -> Wireless Gateway -> ASP -> Database (at financial institution)

Where the Handset was authenticated to the Wireless Gateway via WTLS. The
Wireless Gateway initiated an object request, specified a portion of the
request to be encrypted under a key negotiated with the back end database
(i.e. The ASP could not read that portion of the message.) Meta-Information
about the transaction was bundled with the object request, and sent to the
ASP. The Gateway was authenticated to the ASP, and the ASP passed along the
request along with it's own confirmation that the gateway could be trusted.
When the request was received by the database, it unraveled the whole object
request, trusting it based on the transitive trust chain back to the
wireless gateway.

Granted, WAP and WTLS are poxes upon the face of computing, but, we were
able to get a financial application running pretty quickly, and were
confident that there was no malicious message manipulation. If we had taken
the further step of initiating the object request on the handset, we
wouldn't have had to inherently trust the wireless gateway.

So, what's the moral of the tale? Before you try to convert point-to-point
technologies into n-tier technologies, go and read up on CORBA. There are a
lot of things wrong with CORBA, not the least of which being that a mere
human doesn't have a snowball's chance in hell of really understanding how
everything fits together. However, they did a lot of things right. And if
you dig into the OMG site deep enough, you'll find an archive of the issues
people discussed as things were being discussed.

To make a long story short, if you want a secure n-tier solution, try
starting with something that was designed to be n-tier and then had security
bolted on to it (like CORBA.) Don't start with something that was designed
as a point-to-point protocol, and then had security bolted on to it (like
HTTPR.)
</rant>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]