[OSLC-CM] How many tools support (or plan to) OAuth?

Steve K Speicher sspeiche at us.ibm.com
Mon Nov 30 12:36:10 EST 2009


Olivier Berger <olivier.berger at it-sudparis.eu> wrote on 11/26/2009 
07:29:55 AM:

> Le mercredi 25 novembre 2009 à 08:58 -0500, Steve K Speicher a écrit :
> 
> > Since the terms "authorization" and "authentication" are overloaded, I
> > think it would be best instead of me trying to describe OAuth here
> > that I defer to the http://oauth.netsite for resources that describe
> > it. 
> > 
> > I did not intend to state a subset of OAuth or misrepresent it by
> > saying "cross-system authentication" as it is not a single-sign on
> > solution.  It provides a way to authenticate users, then leverage that
> > to authorize cross-server access. 
> 
> You're right... reading back your initial message, the term
> authentication had triggered some doubts, but I hadn't really noticed
> the "cross-system auth".
> 
> OAuth is really about tokens granted by apps to other apps after
> approval by users, and not a *users* auth mechanism nor a SSO indeed.
> 
> Thanks for the clarification. I think we share the same vision of
> OAuth's role in the protocol.
> 
> 
> What's left to define (maybe ?) is the semantics of such
> privileges/permissions that the servers would support with OAuth maybe ?
> 
> Would it be part of the OSLC-CM standard to explicitely state which
> permissions may be granted to clients through OAuth ?
> 
> For instance I can imagine a use case for a system where a user could be
> prompted to allow delegation of the right to create bugs in a bugtracker
> to a continuous integration tool for a specific "project" or "category"
> only, but not to mark bugs as resolved.
> 
> The "right to create a bug in a particular project" or "right to mark a
> bug as resolved" would then be the kind of permissions granted to client
> tools through OAuth ? 
> That's a bit different than being allowed to access a particular URL
> through POST (as may be easily done with a .htaccess for instance).
> 
> How "far" should OSLC-CM go in this respect in terms of
> standardization ?
> 

In my opinion, these scenarios are looking at what could be possible in 
the future but not what may be needed for simple interaction without the 
specialization around delegated "rights".  From what I've seen of 
some/most tools, they don't have the core architectural support for this 
model and therefore would almost be a non-starter from the beginning. 
Having said all that, the scenario you describe is a real integration 
issue and OAuth appears to provide some existing work to enable it.  As a 
baby step, OAuth helps out with 3-legged model by not flowing the password 
through the intermediate service provider, instead just access tokens.

So back to your original question of *How "far" should OSLC-CM go*, in my 
opinion, as far as warranted (and time allows).  We'll continue to take 
incremental steps to build up value in OSLC-CM.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20091130/b581002f/attachment-0003.html>


More information about the Oslc-Cm mailing list