[jira] Resolved: (SHINDIG-290) Add OAuth and Gadget Token access control systems to API server

["Cassie Doll (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SHINDIG-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cassie Doll resolved SHINDIG-290.
---------------------------------

    Resolution: Fixed
      Assignee: Cassie Doll

This patch was submitted a while ago and the implementation has also changed since then.

> 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
>            Assignee: Cassie Doll
>         Attachments: rest_api_server_auth_system.png, rest_api_server_auth_system.svg, restful-oauth1.txt, restful-oauth2-v2.patch, restful-oauth2-v3.patch, 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.