The Impossible Becomes Real: REST "security" understanding reaches new lows

This is genuinely amusing, Pete Lacey tells us that we have all been missing the boat on message level security, it turns out that we security people were just whiners, we already had what we needed with SSL and Kerberos!

To try and put a positive spin on the WSF, one can look on it as the XML-ification of a number of existing technologies. For instance:

Standard/Spec	maps to
WS-Security	SSL (partly)
WS-SecureConversation	SSL (the rest)
WS-Trust	Kerberos

I have to admit I had a brief flicker of hope when I saw Pete's "partly" after SSL, but that hope was shattered when I saw that "the rest" is covered by SSL's ample "ability" to manage the same use cases as WS-SecureConversation!

One last time: WS-Security is message level security, SSL is transport level. There is a vast ocean of space between where enterprises terminate SSL and where your app is. Go ahead and ask your infrastructure team where SSL is terminated.

Dan Pritchett commented on a previous post on REST's lack of message level security:

Great post. The separation of SSL from security of the message is a concept that is often lost on SOAP developers as well. The need to move to more intelligent routers to handle a variety of QoS tasks is pushing SSL termination further from the application server. Assuming that your SSL connection is getting anywhere near your application is a fallacy.

No question that many (approx. 72%) SOAP developers miss this distinction as well. But the point is that SSL in no way provides what WS-Security does, which is end to end not point to point security, or more specificallly end to end message level confidentiality and integrity. "Hey did my "SSL-protected" message get altered after SSL was terminated?" Good question, boss, I have no idea.

Now there are actually some analogs to how SSL and WS-SecureConversation behave, but again one works at the message level and one doesn't. Oh, and WS-SecureConversation supports a wide variety of token types like SAML, X.509, and Kerberos.

Which brings us to WS-Trust and Kerberos. Sorry but this is just laughable. WS-Trust lets you deal with multiple token types one of which is Kerberos, and Kerberos is fine and all (and yes there are analogs to the WS-Trust behaviors and Kerberos TGTs), but what about domains whose access control depends on X.509, legacy username/passwords (cough, cough mainframe), or SAML? The whole purpose of WS-Trust is that we live in an heterogeneous world, and need to mesh together multiple token types for a given transaction -- in an integrated enterprise any one single token type is not going to be sufficient to traverse all the domains.

There are a lot of really smart people in the REST camp, and a lot of good ideas, but 1995 security models aren't good enough any more than muskets are sufficient for the USMC. The big ask on the REST side is for simplicity. Fine. But let's find simple ways to do message level security in REST not SSL and a prayer.

According to the Viridian Principles 1.0

"Eat What You Kill"

It's perfectly acceptable to supersede some time-honored tool or practice. However, you should take pains to fully comprehend the thing you have rendered obsolescent. You are removing some part, however modest, of the infrastructure of civilization. You are destroying the work of previous designers; you should offer them the respect you yourself would hope for, under similar circumstances. This is for your own good. You can't comprehend your own accomplishment until you have fully internalized and understood the accomplishment that you are undoing.

Of all the Web 1.0 technologies, Web 1.0 security (aka firewalls and SSL) is the least suited to a Web 2.0 world.

Comments

[Joe Gregorio]

"But let's find simple ways to do message level security in REST not SSL and a prayer."

http://atompub.org/rfc4287.html#rfc.section.5

[Gunnar]

Thanks Joe. This is a much better comparison

[James]

Many enterprises use SSL acceleration appliances where SSL is terminated in the DMZ. This is where WS-Security takes over in terms of services that are consumed outside of the enterprise...