ESciDoc Authorization Authentication Architecture

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

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 an internal list containing the object ids
2. the list is provided to the PDP
3. for each entry in the provided list the PDP engine is consulted for allow/deny response
4. all object ids from internal list with allow response are returned back to the item service
5. item service constructs a result list for all objects with allow response and returns the list 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?

Related pages

[and authentication]