SAML and URNs

SAML
I am reading through the SAML specifications in an effort to understand Shibboleth. OpenID seems to be a competing technology to solve the single sign on(SSO) problem. OpenID is a grassroots effect, while Shibboleth is industry lead, so it will be interesting to see who wins this one. Shibboleth offers more functionality by going beyond just supporting idenity, it can also provide attributes about the user that can be used by a service for making authorization decisions. The cost of this is complexity and performance: lots of XML that has to be signed and encrypted.

One interesting thing in the SAML specs is that it states that Web proxies should not cache certain messages. Is it worth while saying this, can you really trust proxies to do what you ask them? (Byzantine faults) What are the consequences if they do cache them?

The real point of this post is this URI from SAML 2.0:

urn:oasis:names:tc:SAML:2.0:status:Success

Tried clicking on it? First it should be a http URI

Second I am concerned about the 2.0. Has success been redefined since SAML 1.0?

Now for a bit of HTTP bashing. Even toddlers know what HTTP 200, 404, 201 etc mean. But can we reuse them in other specs. Maybe if they were URIs! Why are the error codes in HTTP not URIs? Anything that can have a URI can be a resource, surely 404 deserves to have URI.

WS-Security, simple enough to shoot yourself in the foot with.

WS-Security, simple enough to shoot yourself in the foot with.
Gunnar Peterson's critiques REST security in terms of WS-Security, I just have to comment. Frist I have helped implement WS-Security in Perl, in particular signing, so I got to know the specs pretty well. Some good things about message level security and WS-Security:

1) The WS-Security spec is pretty good and well thought out by people who know the issues. It was a learning experience for me.

2) Message level security is much more flexible than transport layer security. You can go beyond simple client/server architecture,
so you can go beyond what REST. For example in the Grid world you could use message level security to build a resource broker:
client submits a job submission message to a resource broker, resource broker picks resource and sends message to resource, resource authenicates message and runs job. (OK there is a whole issue of what the hell you do with the WS-Addressing headers, if the client signs the wsa:To then how do you forward the message on).

Now the difficult stuff: how many people know why you must sign the X509 token you use to sign a message? Reason: mutiple certificates
can share the same public key but have different authorization levels, you don't want someone switching certificates and getting different access rights. How many people know you need to include a timestamp to avoid repeat attacks when signing messages? You will also need a unique message ID along with that timestamp, luckily WS-Addressing provides one - did you know that you need to sign WS-Addressing headers to secure messages? You better record those timestamps & message IDs, so you are gonna need transactional writes. Also signing/encrypting at the XML level is pretty slow - so many bits to sign, all that XML Canonicalization etc, so you might need a few extra servers; of course with them all accessing the same stable storage for every message to check message IDs and timestamps. Oh, and better make sure the client/server clocks are synch'd, cause it can be a pain to debug if not.

Of course the toolkits will handle this for you. Wrong. In WSRF::Lite it automatically included and signed the X509 cert and timestamp, part of WS-Security spec strongly recommends this. Then someone from a huge(TM) company asked if this could be turned off on the client side as the service developed using some big name toolkit didn't use this. I pointed out that this could be a security vulnerability and that they should also be signing WS-Addressing headers, I got a "well I duno anything about that, but the client wants it this way" - well I hope they are using that gigantic hole in the firewall, AKA SSL. People too often think that just turning on WS-Security will make their application secure.

As for REST, XML signature and encryption can be used in REST. In fact it might be eashier as you don't get caught in the flat structure of SOAP Header/Body - you can use a Russian doll model (or onion model) of embedding XML in XML, each service peels of the layer it is interested in before passing the message onto the next service. No service has to understand the XML in any other layer but its own. This is the model that we had planned for HARC, it will be interesting to see if it works ;-)

For more pain on this subject see: Taverna and Security