[
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.
