ESciDoc Authorization Authentication Architecture

From MPDLMediaWiki
Revision as of 12:30, 15 October 2007 by Natasab (talk | contribs)
Jump to navigation Jump to search

Present architecture

At present only core services are secured:

  1. Each resource handler has built-in service interceptor that is intercepting all requests to the service
  2. The service interceptor analyzes the request and forwards it to the PDP engine
  3. The PDP engine provides allow/deny response for the request
  4. In case of deny response from the PDP engine the service responses with a security exception to the service requester

Img service interceptor.jpg

The figure above gives a very simple example for the authorization mechanism. However, in case when the user requests e.g. a list of items from the ItemService based on a certain filter or query criteria the authorization must be evaluated for each item respectively (note more info from Torsten needed):

  1. Item service analyzes the filter/query criteria and creates the internal result list
  2. for each entry in the result list the PDP engine is consulted for allow/deny response
  3. all entries from internal result list with allow response are returned back to the service requester

Issues

Note: Torsten, please check if this is true

  • In case when the core service requester would like to perform more actions subsequently, then each request is evaluated separately - even in case when the same policy should be applied for all requests.
  • In case when another service that builds upon a core service would like to define own policies: it has to build own service interceptor for own policies (the PDP component can be actually reused). Should we prevent (is it possible to prevent) the double check (on both service side and on core service side) - i.e. trusted service concept possible?
  • is current service interface architecture and policy definition optimized for retrieval/update of multiple resource objects?