The project I work on (and previously described here) requires message authentication. By that I mean the recipient of a message needs to know and verify the identity the message is about. That functionality is usually carried out by adding a security token to the message. SAML defines a very flexible format for such security token, called authentication assertion (note: SAML also defines a set of protocols to provide single sign on as well as single log out).

OAuth provides a nice, standardized, way of conveying (and obtaining) a security token in an HTTP based environment. Since our framework is a RESTful one and in an attempt to not reinvent the wheel, we thought we should leverage OAuth’s mechanism as far as message authentication goes. Namely, we tested to inject a SAML authentication assertion in HTTP’s Authorization header as defined in OAuth.

Before describing the issue, it is important to remember that carrying a security token is one thing, trusting its content (and integrity) is another. Part of the validation process for a SAML assertion is for its recipient to confirm the subject of the assertion. That is, to verify the correspondence between the principal (i.e. the subject) described in the assertion and the party with whom the recipient is conversing with. There are several methods for subject confirmation, but in many cases (at least in our project) Holder-of-Key (HoK) is the method that’s used. In the HoK case, the assertion contains digital signature information (<ds:KeyInfo>) that must match the also embedded X.509 public key certificate data.

Such assertion can get you at around 5KB and that’s where the problem lies. Most web servers out there, when left on their default settings won’t support headers of that size…

So we need to find an alternative to this approach.

One idea would be to switch to different type of tokens, possibly binary ones like Kerberos in the hope of making it smaller. However a Kerberos token can get pretty big too since nesting (of groups) is possible. Also we’d loose a lot of the flexibility that comes with SAML tokens.

So what can we do?
I’ll post a follow up soon on the solution we’ve devised but of course suggestions are more than welcome!