Please take a look at a diagram I've created that has some initial thoughts on how the oauth and token systems can be merged and what extra pieces are necessary to support oauth: https://issues.apache.org/jira/secure/attachment/12382437/rest_api_server_auth_system.png
davep On Wed, May 21, 2008 at 12:16 AM, David Primmer (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > David Primmer updated SHINDIG-290: > ---------------------------------- > > Attachment: rest_api_server_auth_system.svg > rest_api_server_auth_system.png > > I'm attaching a png and an svg (created with inkscape) of the components I'm > proposing for an access managment system for the api server. > >> 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 >> >> >> 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. > >
