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 :

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

Performance issues

Authorization of a method access

• Overhead due to remote call from the policy enforcement point within the infrastructure core services to the policy decision point service.
• Evaluation of authorization requests within the policy decision point:
  • Xacml engine needs approx. 25-33% of evaluation time.
  • Fetching of attributes during policy evaluation needs approx. 66-75% of evaluation time. Currently, a single attribute of a resource is fetched when it is needed by the Xacml engine to evaluate a policy. It has to be checked, if this could be optimized by fetching all attributes of a resource at one time, even if some (or most) of them will not be needed during the authorization.

Filtering of resource lists

Filtering a list of resources in respect to the privileges of a user seems to be the most important problem related to AA performance. Even if the privileges could be evaluated for a single resource in e.g. 1 ms, this would lead to a long time for a large list of e.g. 1.000.000 (1000 seconds) resources. Therefore, other approaches than query the triple store for a list of resources followed by filtering the result list seems to be needed.

• Triple store only returns resources that the user is allowed to access. One solution could be to translate the policies to a triple store query and combine this authorization query with the original filter query. In this case, the triple store would only return the "allowed" resources and no further authorization steps would be needed.

Upcoming architecture

The authorization at a core service level only is not sufficient in cases where other (i.e. application, intermediate eSciDoc services) are invoked. Therefore we have considered several alternatives for providing authorization at all levels of the eSciDoc SOA infrastructure. Issues we have considered is to:

• avoid duplicate authorization for an operation of a resource that is performed at all levels of the eSciDoc SOA
• authorize at each level on the eSciDoc SOA
• make the authorization architecture simpler

We have considered:

• alternative where services trust each other by providing a signed messages (Called service will not question the authorization perfomed by the core service in case when called service has been provided with a signed message. The signed message does not contain information on operation and resources for which the authorization has been approved)
• alternative where services trust each other, but in addition they must provide to the calling service a request handler id, which is stored with the eSciDoc PDP and which contains an information for which operations and for which resources the request is valid. This will be checked by the called service and will ensure that the authorized operation is performed on authorized resources only. This alternative is at present discarded as too complex.

Therefore we have preliminary agreed on:

1. Services within the eSciDoc SOA will be "trusted"
2. A trusted eSciDoc service will provide it's own PEP (Policy Enformcement Point)
3. A trusted eSciDoc service will store it's authorization policies in the eSciDoc PDP (Policy Decision Point) engine

When a trusted eSciDoc service needs to perform an operation that requires invocation of another eSciDoc service operation it has to provide a signed message to the invoked eSciDoc service. If the message is correctly validated, the invoked eSciDoc service will not perform additional authorization (in opposite case the invoked eSciDoc service PEP will have to perform additional authorization).

For the purpose of setting up this authorization infrastructure we need to implement mechanisms that will enable:

• service identification (i.e. simplified form of a service repository of trusted services)
• trusted messages infrastructure (following WS-Security standards see also Web services security as short intro)

Issues

• 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?

There are two situations that have to be considered:

• • The policies of the non-core service are based on core service actions, only.

In this case, the non-core service does not need to implement own service interceptors. All that has to be done is to define the policies in a (new) role (see RoleHandler), and to grant the role to the users (see UserAccountHandler).

• • The non-core service defines own actions that have to be authorized for the users.

In this case, the non-core service should implement the policy enforcement point that calls the PDP component to decide, if the request shall be authorized or shall be declined.

Currently, the 2nd situation leads to a double authorization check in the non-core service and in the core services. This could be prevented, e.g. by skipping the authorization step in the core services, if a trusted non-core service connects to it:

• • The calling service "signs" the request. If this is successfully evaluated, the core service skips its authorization step.
  • The core services are protected by some external mechanisms like a firewall that assures the trusted services can connect to the core services, only. In this case, the authorization step in the core services is always skipped.

--Natasa 13:47, 20 November 2007 (CET) In general (based on requirements so far) we probably have both situations: i.e. some services will rely only on core-service authorization and some will provide own actions(e.g. workflow actions) and own policies that need to be evaluated. Question for second situation (i.e. own-actions of a non-core service): are both steps in authorization necessary or the first step (i.e. where calling service "signs" the request as evaluated positively) is sufficient?) - How do we make certain that we exactly know which instance of a non-core service is "trusted" and which not (this is related in addition probably also to the topic of a service repository?)

• --Natasa 10:35, 26 November 2007 (CET) is current service interface architecture and policy definition optimized for retrieval/update of multiple resource objects? This is even more important question now. For example will the authorization flow proceed as in the case depicted as below (please use the service authorization diagram from above to visualize):
  • Service B has a request for retrieveItems authorized and forwards this request to Service A
  • if Service A does not cross-check the authorization rules again ("translated" to Service A retrieve methods) then Service A call may result with e.g. 10000 items in the list
  • must Service B cross check all 10000 items and finally decide to give to the user 100 items back ? (this is something we would certainly like to avoid)
  • must Service B must create its query in accordance with service A authorization policies?

Related pages

• Authorization and authentication

Enhanced Scientific Documentation

Service-Oriented Architecture

Central European Time