Hi Bram, I could live with a separate subproject. Question is how we will position other authorization/authentication related bundles that will be implemented in the future, like OpenID. Maybe it would be good to define a subproject 'amdatu-authentication', containing oAuth and in the future OpenID authentication (and maybe even NTLM). Both the login gadget and login service by the way will depend on oAuth in the future. Currently a non-oAuth security token is used to authenticate client requests in the opensocial container, but it would be better to use an oAuth encrypted token for that too. The login gadget should generate and authorize this token. For requests not proxied via the opensocial container, something should provide the client with an authorized token, which I think should be the login service. There are not much oAuth libraries out there, so the only alternative would be to write them ourselves from scratch, which is certainly not our core business.
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: dinsdag 16 november 2010 13:41 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] oAuth 2010/11/16 Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com>: > Hi All, > > > I'm looking in more detail to the oAuth improvements scheduled for 0.1.0. > Currently, oAuth ?provisioning is implemented by Shindig which registers an > oAuth servlet that supports generating the request tokens, authorizing > tokens and exchanging request for access tokens. Despite the fact that this > is not yet completely implemented (i.e. three legged oAuth is not yet > supported), we need to think about how we should position oAuth support in > Amdatu. > > In my opinion, oAuth support (client-side and server-side) should be > implemented completely independent from OpenSocial, Shindig, Gadgets, etc. Agreed, I'd like to see this standalone. > Any (REST, gadget. etc) service should be able to authenticate consumers > against oAuth and register itself as an oAuth provider. Consumers might be > gadgets but could very well be other REST or OSGi services. Yes, I'd also like a service API for requesting tokens and doing signed requests. > So my proposal would be to move oAuth to a separate independent oAuth bundle > and from the opensocial project to the amdatu-authorization project. oAuth > actually is about authentication, not authorization, but that is more of a > naming issue of the project I think ('amdatu-authorization&authentication'). > It certainly doesn't belong to amdatu-opensocial or amdatu-web, and also not Isn't it a subproject in its own right? I'm not really clear on what the scope, purpose or responsibility of amdatu-authorization is. I think a subproject should represent be a coherent set of bundles that perform a function (call it a composite if you will) and I do not yet see that for this one.. eg oauth should not have anything to do with a login gadget. The former is more of a generic service where the latter is a specific application level component. feels like layer skipping to me. > in amdatu-core I think. Furthermore, I would like to use the net.oauth > library in that bundle (not Scribe since it doesn't support oAuth > provisioning). See also issue http://jira.amdatu.org/jira/browse/AMDATU-181 It does not seem to have an SPI for the HTTP wire which is kind of a shame. In general I think we should guard against too many ad-hoc point-to-point connections all over the place. That will create a configuration/deployment/ configuration nightmare. The again, neither does scribe it appears :) Regards, Bram _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
