Akenti

Akenti, developed by Lawrence Berkeley National Laboratory (LBNL), is an example of resource level authorization. Though developed with Web resources in mind, the concept was later extended to include resources in a grid computing VO setup. The Akenti model consists of resources, which may include Web resources, distributed grid resources that are being ac- cessed via a resource gateway (or a Policy Enforcement Point or PEP) by a set of users who are the part of the virtual organization. The model also as- sumes that each resource may have multiple stakeholders having a set of access constraints on the set of resources. The Akenti system allows the users to access the resource(s) based on the identity of the users and the access policy set on the resources by the resource stakeholders. The stake- holders express their access constraints through a set of self-signed certifi- cates which are known to be stored in a secure remote server. The certifi- cates express the attributes a user must have to access the resources. At the time of resource access, the resource gatekeeper or the PEP asks the Akenti server what access the user has to the resource. The Akenti server finds all the relevant certificates, verifies the certificates, and the returns the decision to grant the access to the user.

bility of the system if the policies are complicated and take some time to parse and understand. However, most of the enterprise grid requirements are

5.4 Resource Level Authorization Systems 91

Fig. 5.11. A high level view of the Akenti authorization system

Figure 5.11 shows a high level view of the Akenti authorization sys- tem. To access a certain resource, a user sends a request to the resource gateway or the Policy Enforcement Point (PEP) with the user credentials or the user identity certificates. The PEP asks the Akenti server about the decision to grant access to the user. The Akenti searches for the different certificates of the stakeholders which include the policy certificates and the use condition certificates, which may be in remote locations. Once the cer- tificates are obtained, the Akenti server verifies them and grants the user the access to the resource which is enforced by the PEP or the resource gatekeeper.

Akenti assumes that all the certificates follow the X.509 specification, and SSL/TLS channels, are used to authenticate a user who wants to access the resource. Policy certificates are created by unrelated stakeholders from multiple domains, and the access to a certain resources is determined by the combined policy on the resource by the different stakeholders. As is clear from the discussion, Akenti uses a classical pull model. The user pre- sents the credentials to Akenti, and it “pulls” the different certificates from remote locations and makes the access decision.

Akenti policies are expressed in XML and stored in three types of signed certificates: policy certificates, which specify the sources of author- ity for the resources; use condition certificates, which specify the con- straints that control the access to a resource; and attribute certificates which specify the attributes to the users that are needed to satisfy the use conditions. The connection between the different certificates is provided in Fig. 5.12.

Let us look at the different certificates in detail:

• Policy Certificates: Policy certificates are signed certificates, generally located with the resources. It contains information re- garding the stakeholders and the location of the use-condition certificates of the stakeholders for the resource. These certifi- cates are signed by CAs which are used for validation by the Akenti policy engine. A policy certificate may also contain a list of URLs where to search for the attribute certificates. Dif- ferent resource groups controlled by Akenti authorization sys- tem have a single policy certificate, which is generally stored in a known and secure place.

• Use Condition Certificates: The second type of certificate used by the Akenti authorization system is the use-condition certificate. Each stakeholder group for a resource creates one or multiple use-condition certificates for the resources. A use- condition certificate consists of a set of constraints that deter- mine the rights a user must have to access a set of resources. Akenti use-condition certificates allow the use of a X.509 dis- tinguished name as an attribute. It also allows resource or real- time attributes to be specified.

• Attribute Certificates: Attribute certificates contain an attrib- ute-value pair and the principle to which the attribute applies. The attribute certificates are signed by the attribute authorities that have been specified in the use-condition certificate. They generally apply to a single resource, or a group of resource or resource realm.

To determine whether a user can be granted access to the resource, the Akenti policy engine finds all the use-conditions by searching in the URLs specified in the policy certificates and verifying the issuer and sig- nature on each certificate. If the use-condition certificate cannot be found for each stakeholder, access to the resource is denied. Attribute certificates

5.4 Resource Level Authorization Systems 93 are searched by following the URLs specified in either the policy certifi- cate or the use-condition certificate. Akenti caches all the certificates so that the search latency is reduced. The lifetime of the cached certificates is set in the policy certificate for the resource.

Let us now focus on the different characteristics and applicability of the Akenti system.

Fig. 5.12. Relationship between the different certificates

Comments on Akenti

Akenti was initially designed to control Web resources, where there are multiple stakeholders for the resources and there are lots of users trying to access the resources. With the advent of grid and collaborative computing, Akenti has been seen as an important alternative to different centralized VO based systems like CAS, VOMS, etc. Akenti does provide flexibility as the use condition certificates can be changed over time. Let us look at the different characteristics and applicability of the Akenti system.

• Applicability: Akenti has been designed for providing access to the Web sites and Web resources. In a VO sense, a centralized pol- icy database with a CAS and VOMS system does suffice most of the times. If there are resource specific policies, then that can be implemented at the local resource level. Akenti, on the other hand, can be applied in cases where there is an enterprise level grid hav- ing multiple enterprises or stakeholders managing the grid. Then, an Akenti type of system will have a lot of relevance. An integra- tion of VO level systems and Akenti can also be thought of. How- ever, in its current form Akenti cannot be directly used in an enter- prise scenario because of lack of support for upcoming standards like SAML, and lack of support for more sophisticated enterprise policies in terms of different types of licenses and so on.

• Scalability: Akenti uses a pull model, therefore there is a loss of scalability when the number of users is large, as the Akenti system checks the policies and makes an access decision every time. How- ever, from the administrators’ point of view the solution Akenti is scalable as attribute certificates, policy certificates, and use condi- tion certificates are decoupled and can be changed without affect- ing the main system.

• Security and Revocation: Akenti security characteristics are simi- lar to any other authorization system, and do not introduce any ex- tra security vulnerability. However, the certificates need to be se- curely stored. Compared to CAS and VOMS, since Akenti applies a pull based mechanism, revocation is faster as changes made to the use-conditions are effected immediately.

5.4.2 Privilege and Role Management Infrastructure