The first step of the scenario is not possible; in the authorize step you cannot possibly know the REST service being invoked by the consumer. So the permission scheme to apply can only be configured per consumer. This means that this information could best be stored in the consumer registry. It should support persistence of a collection of permission properties, consisting of:

  • id
  • name per locale (used in authorize step)

Proposed solution: enhance the authorize token servlet to post additional token parameters, which are included in the access token. Note that the Token API already supports adding custom properties. Furthermore, the consumer registry should support defining custom authorization options. There would be two types: radio and check options. Radio option for example would be 'define access' with options 'read only' and 'read/write'. Check option for example would be 'allow service to read your address' (yes/no).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers

Reply via email to