Hi Sergey, Thanks for replay. Yes, I think will be better to start from OAuth support for REST part, as I am more familiar with that.
One of the OAuth profiles called Autonomous Client Profile does not require user action. Simply client's login and password (this data has to be obtained from OAuth Authorization Server before) is exchanged for an access token. Instead of login and password could be used some kind of assertion i.e. SAML. I think it is that what you meant. According permissions, OAuth spec does not tell how permissions are captured by client since there are too many possible approaches to permissions to be covered in spec. So it always depends on Authorization Server implementation. I think Flickr and Twitter API have done it somehow. Sorry for late answer, but I was kind of offline last days. Cheers, Lukasz 2010/4/9 Sergey Beryozkin <[email protected]> > Hi Łukasz > > Thanks for your proposal. > In fact, a number of users have already asked about OAuth, so I think it > will be a good enhancement. Please note SOAP users have asked as well, so > as > far as the communication between the Consumer and server-side OAuth filters > is concerned, it may be worth supporting the SOAP communications too. I > don't have the experience in this area but I believe both RESTful and SOAP > based interactions are supported. We can add a SOAP-based code at a later > stage but the idea is that ultimately all CXF users get the benefit. > > One thing which I'd like you to consider, as far as this proposal is > concerned, is how/if an automatic consumer authorization can be achieved on > the CXF client side. Awhile back, we gave some serious consideration to the > idea of the client-side CAS [1] support in CXF with my friend and former > colleague who is a security expert but no production requirement came in. > Specifically, [2] says that an application client issues a request to the > CAS Server providing an application request URI as a query parameter but > presumably this should happen invisibly to the client, the client invokes > directly on the application URI but since it has not been authenticated yet > it is *redirected* to the CAS server. The CAS server will eventually try to > authenticate the user. > > CXF HTTPConduit[3] can do the auto redirection but we thought we could have > HTTPConduit injected with say RedirectHandler which can customize the way > the current redirection is dealt with. So say, a CAS redirector could do > the > redirect but when presented with the login page it could just reply with > some configured name/password, etc, or may be provide them immediately to > the CAS server, without waiting for the login request, so we thought it > could provide for the automatic handling of the user login requests. > > CAS and say OpenId are slightly different from OpenAuth but I'm wondering, > can a protected resource owner somehow manage to authorize a consumer using > the HTTPConduit idea ? Ex, OpenAuthAuthorizer can have be configured with a > list of trusted 3rd party providers and the permissions they may have. No > problems if not, I'm not sure how the resources server asks the owner to > authorize, so feel free to ignore this part. > > I will create a CXF JIRA and then please start working on the concrete > proposal. I'll be happy to be a mentor and will look forward to learning > few > things about OpenAuth. > > cheers, Sergey > > [1] http://www.jasig.org/cas > [2] http://www.ja-sig.org/wiki/display/CASUM/Technical+Overview > [3] > > http://svn.apache.org/repos/asf/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java > > On Fri, Apr 9, 2010 at 8:08 AM, Łukasz Moreń <[email protected]> > wrote: > > > My name is Lukasz Moren and I'm a student looking for an interesting > > project > > for this year Google > > Summer of Code. > > > > I would like to propose a project idea: Provide an authentication support > > through OAuth for Apache CXF (JAXRS module). > > Something similar to: [1], I mean the idea, not execution. > > > > As I am recently involved in RESTful services (mainly RESTEasy framework, > > but I've tried also CXF:)) and OAuth protocol, > > it's area I feel good. > > > > The OAuth community works currently on: [2], which appeared after 1.0a. > > and planning 2.0 release based on OAuth WRAP:[3]. > > > > I take part in GSoC 2009 in JBoss [4], and project finished sucessfully. > > I was mainly involved in two tasks: [5], [6], hovewer the second one > became > > big > > and development is continued here: [7]. > > More info about me can be found: [8] > > > > > > [1] > > > > > http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.2.GA/userguide/html/Authentication.html > > [2] http://wiki.oauth.net/OAuth-WRAP > > [3] http://hueniverse.com/2009/11/planning-for-oauth-2-0/ > > [4] > > > > > http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/redhat/t124024692589 > > [5] > http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-392 > > [6] > http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-307 > > [7] https://jira.jboss.org/jira/browse/ISPN/component/12312732 > > [8] > > > > > http://www.linkedin.com/profile?viewProfile=&key=32578698&locale=en_US&trk=tab_pro > > > > Sorry for so much links, but I would like to exaplain things briefly. > > > > Please let me know what do you think about that idea. > > > > Thanks in advance for reply. > > > > Best Regards, > > Lukasz Moren > > >
