A claim by any other name is still a claim even if its Restful

I am really enjoying this wonderful new world of Claims-based access control (CBAC), and I think the way that the encryption and signatures have been packaged up into claims (if you like your coffee with WS-*) or assertions (if you like a dab of SAML) is allowing us to deploy security architectures that solve a lot of age old problems. I call 'em claims even though MS/IBM hijacked the term from the SAML people it is shorter.

Rest application need claims too. As Don Box says the rest authentication story blows chunks. Now, you see people reinventing WS-Security in Rest (because they realize they need stronger claims) and unfortunately choosing the weakest token the Username token, which in turn encourages bad programming practice. Piers Cawley on the Rest authentication tarpit:

The problem with implementing the Atom Publishing Protocol is that one of the client apps that we want to support, Nokia’s LifeBlog mobile app, only supports the adaptation of the WSSE UserToken authentication protocol recommended by Marc Pilgrim. There’s lots to like about this protocol, especially the way it allows CGI based servers to take control of authentication without needing access to Apache’s .htaccess or requiring mod_digest to be installed. However, the design of the protocol is such that there’s no way to avoid storing the user’s password in plain text on the server. Which we really, really, really don’t want to have to do.

This would not be a big deal if it was just a one off, but your authentication story is the key to your access control and while authentication can never be perfect, there is a lot of evidence that good ol' username and password isn't that good any more. The problem is not with WS-Security, the problem is the token. While Rest people are reinventing WS-Security they should feel free to not use the username token and instead graduate to Kerberos, X.509, and SAML tokens.

A claim by any other name is still a claim, but some claims are stronger than others.

My larger problem with how I see Rest applications doing authentication is that they still after all these years rely on the old school approach where the server authenticates everything. Umm...are we on a mainframe or something? Why not separate the identity provider from the service provider like the rest of the world? Why send your authN creds across the wire every time? I have not tried but I assume an adapter to some of the SAML profiles would yield this separation quite nicely and give back an address to talk to, and the authN/authZ negotiation could be handled by the IdP and SP allowing the Rest client to talk directly to HTTP verbs served by the server...

Comments

[stu]

I had thought that's what OpenID and OAuth were for...