Fig-6: Authorization.
Authorization is everywhere in TAS3 Architecture. It often gets rolled up in small, but very meaningful symbol in the architecture. This is why we call authorization a "subcontinent" unto itself. It is described more fully in [TAS3D71IdMAnAz]. This section addresses Reqs. D1.2-2.19-AzCredi, D1.2-2.20-Az, D1.2-4.5-ComplyPolicy, D1.2-4.6-BrkGlass, D1.2-6.4-Min, D1.2-7.6-Az.
Fig-6: Authorization.
Fig-6 depicts some of the components involved in the authorization. By far the most common case is that some payload service, such as a Front End or Web Service, needs to get an authorization decision and initiates the subflow.
Policy Enforcement Point (PEP). This is a software module usually built into the payload service. There are four fundamental types of PEP, as shown in Fig-4: in and out variants on Service Requester and Service Responder sides.
Master Policy Decision Point (Master PDP). The PEP calls Master PDP to obtain the authorization decision. Typically each oranization will run a Master PDP (though other arrangements are possible). All logic of the authorization decision is masked behind the Master PDP. Thus the exact implementation details of Policy Decision Point Stack are irrelevant for the PEPs. The MastePDP handles coordination and routing of requests to the PDPs in the stack and aggregates the authorization decisions received from the PDP. In a way it can be viewed as a PDP proxy with some smarts in it.
The Master PDP is responsible for arranging Break-the-Glass Authorization, see Section 3.5 and [TAS3D71IdMAnAz].
Trust Network PDP processes the policies that are coordinated at the Trust Network level. It can be implemented as a central Trust Network-wide service, or it can be distributed so that there is an instance of a Trust Network PDP at each SP, but the policies are centrally coordinated and pushed to the instances, perhaps using the Trust Network Process Manager.
Organization PDP processes the policies that an organization maintains. These policies may be over and above the the Trust Network-wide policies. The distinction from Trust Network PDP is maintained because the authority for deciding the policies is different.
User PDP function may implement User specific policies, i.e. policies set by the User. This could also involve evaluation of Sticky Policies. In practise, the User PDP may be implemented inside the Master PDP process.
Trust PDP is an interface to the Trust and Reputation Management subsystem which allows the Master PDP to query whether a contemplated action is acceptable from Trust and Reputation perspective. Such query has the advantage that the Trust and Reputation system does not need to disclose to the Master PDP the exact parameters that lead to this decision. The deliverables of WP5 will elaborate on structure and design of Trust PDP and Trust and Reputation System at large.
Credential Validation Service (CVS) is a subsystem that helps PEP to establish the validity of the credentials and attributes it is about to pass to the Master PDP. Typically these are received from front channel interaction or from an earlier web service call. The validation involves checking that they are properly signed and that PKI trust to the signing authority exists. Some namespace and syntax checks may be performed as well. The CVS may call on other components of the architecture to perform its functions.
Policy Information Point (PIP) is used to fetch additional attributes that may be needed for policy evaluation. PIP may call, in a recursive manner, on other components of the architecture to perform its functions. Special care needs to be taken in preventing infinite recursion and to ensure that the policies in the recursive levels allow the information to be returned for purpose of policy evaluation. PIP may be called either from PEP or from Master PDP. Exact choice is a question of optimization. The set of attributes needed for policy evaluation is difficult to determine. This is a research problem we hope to solve.