OpenSAML user discussion

["Scott Cantor" <>]

> As for RESTful approach, I read on one of the blogs
> http://weblogs.asp.net/cibrax/archive/2009/03/06/brokered-authentication-
> for-rest-active-clients-with-saml.aspx
> 
> that you can inject the token in the HTTP Header (Authorization field) .

Assuming you're ok with it breaking on a lot of web servers, sure. Headers
are quite limited in size in many configurations.

> Is this viable approach given this blog talks about Geneva as their
> underlying implementation.

If it works on IIS, then presumably they've left the header limits very
relaxed, but it won't fly on Apache in most cases.

> I am speculating when they are talking about tokens, they are referring to
> SAML assertions. If that being the case, you did mention that SAML cannot
> adapt to OAuth because Assertions cannot be serialized into headers.

You can put anything into a header but that doesn't make it fit. OAuth is
optimized for small bearer tokens issued by the service you're sending the
request to. Once you split the issuer off, you need a standard format, and
you need semantics that bloat the size. More importantly, you need a
signature and you're blown.

Besides that, you're gaining...nothing. Most use cases include messages back
and forth and it's not efficient to process a signed token on every request,
and you'll end up with a cookie-like thing anyway. So the choice is an
inefficient mechanism that's proprietary and doesn't support sessions
directly, or a mechanism based on a standard SAML profile and assumes
session semantics already provided by the SSO software.

-- Scott