OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

>> 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.

At some level that's true and I'll admit that I characterized it as a
gateway approach - it's a natural step when you sell a gateway style
product:)    But the authorization server doesn't necessary have to be
a distinct entity, it could be an additional endpoint at the service.
 At another level it's nothing more than exchanging SAML for some
session token.  But it's happening within the framework of a standard
which is good for interoperability.

>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.

I don't disagree with your characterizations, however, I'd say all
those points could be considered good or bad depending on your
perspective and needs.  Trade-offs are unavoidable.

> 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.

The token is both issued and consumed by the same party (in the most
common use case anyway) and it is opaque to the client so it can
contain whatever that entity deems necessary in whatever format makes
the most sense for it.

The scenario I described is just one method of obtaining an OAuth
token and it's the "two-legged" approach that is more appropriate for
situations where the authorization of the end user is implicit in the
relationship between the two providers (often due to employer/employee
relationship but maybe health-care fits it too).  Most of the other
methods of token acquisition are "three-legged" and involve the direct
participation of the end-user to grant the access.   The method of
presenting the token in HTTP based API calls is standardized and
decoupled from how the token was acquired.   I do think there's value
in that but I think I've digressed a bit from John's original

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]