I submitted a new version of the patch - restful-oauth2-v2.patch<https://issues.apache.org/jira/secure/attachment/12385008/restful-oauth2-v2.patch>
Dirk. On Mon, Jun 30, 2008 at 5:22 PM, David Primmer (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609412#action_12609412] > > David Primmer commented on SHINDIG-290: > --------------------------------------- > > Brian, > > Thanks for this very thorough review. I agree with many of your points, > especially on the UserPrinciple. However, I would like to see this patch > committed in the current state. I don't think we need to get it perfect on > the first submit. The first commit of this code did pretty much nothing and > we were hoping to gradually build on that, in the same way that the social > api server is gradually coming along. This excellent list of todo's could > keep Dirk or others busy for a while. So I think the main reason not to > submit it would be if it was going generally in the wrong direction, and I > don't think that's the case. I think the policy of the this area of the > codebase has been a liberal mix of 'commit, then review' and 'review, then > commit'. We have a while to work on things until the server is considered > spec compliant. > > > Add OAuth and Gadget Token access control systems to API server > > --------------------------------------------------------------- > > > > Key: SHINDIG-290 > > URL: https://issues.apache.org/jira/browse/SHINDIG-290 > > Project: Shindig > > Issue Type: New Feature > > Components: RESTful API (Java) > > Reporter: David Primmer > > Attachments: rest_api_server_auth_system.png, > rest_api_server_auth_system.svg, restful-oauth1.txt, restful-oauth2.patch > > > > > > The server should be able to get auth info from both the gadget token and > an oauth access token and after inspecting them, figure out the attributes > necessary to pass on to the backend. There may be complicated rules for > attribute precedence depending on the context of the request. A servlet > filter is assumed to be the implementation and its also assumed that this > would not be a throw-away system, as few of these actually exist, it might > as well be a decent one. Current social soken handling can also be moved to > a servlet filter for parity. > > In addition, there should be a simple Access Management system that can > store access control lists and potentially delegations that the API server > can refer to for data access decisions. This Policy Decision Point should be > of limited scope and it's assumed it will be based on the standard Java > security libraries. Policy enforcement will still happen in the social api > data service layer. > > And Identity provider / login mechanism and GUI for delegating > permissions (needed for the OAuth three-legged flow) is the most "out of > scope" for shindig and it should be developed as a very simple and separate > system to take credentials, take a delegation decision and store it in the > Access Managment system. > > (I write this rather elaborate feature request knowing that I have a > diagram illustrating this.) ;-) > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
