[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 question.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]