You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "David Primmer (JIRA)" <ji...@apache.org> on 2008/05/21 09:16:55 UTC
[jira] Updated: (SHINDIG-290) Add OAuth and Gadget Token access
control systems to API server
[ 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.
Re: [jira] Updated: (SHINDIG-290) Add OAuth and Gadget Token access control systems to API server
Posted by David Primmer <da...@gmail.com>.
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) <ji...@apache.org> 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.
>
>