RE: [saml-dev] RE: How to provide SAML assertions in RESTful services

["Scott Cantor" <cantor.2@osu.edu>]

> -OAuth 2.0 is still in draft not yet stable.
> -The assertion access grant request suggests the possible use of SAML
> but was intentionally left open ended as an extension point in the
> core OAuth spec.  I'm currently working on an internet draft titled,
> "SAML 2.0 Bearer Assertion Profile for OAuth 2.0" that is intended to
> provide a tight and interoperable instantiation of the assertion
> access grant.  I hope to have an initial draft of that available soon.
> The way the client obtains the assertion is not defined but there are
> a number of ways to accomplish that and it sounds like you've already
> got that part solved anyway.
> 
> Okay Scott, have at it...

I would characterize this as the same old gateway vs. end to end argument
I'm always in the middle of. In essence, the SAML+OAuth approach:

- introduces a gateway whose job is to translate the SAML token into
something else, which now has to be defined
- adds a point of failure (the gateway)
- moves the point of trust management from the services to the gateway (this
is good and bad at the same time)

The SAML approach:

- requires the service to consume the SAML token
- doesn't require a gateway/translator and eliminates the need to define and
consume the additional token format
- leaves the point of trust management with the services (again, both good
and bad)

So, same old issues, and same old opinion about it from me, but maybe it's
useful to see that it's a well-understood question.

Perhaps a useful criteria to apply would also be the requirements around the
additional token. If it's just a yes/no authorization grant, that's pretty
simple. If it's a generically extensible set of data about a subject, let
alone add additional complexity, I have a hard time seeing the point.

-- Scott