|
 |
|
|||||
|
|||||||
|
Managing Authorisationsby Babak Sadighi Firozabadi and Mads Dam The problem of authorisation, delegation, and authorisation management in distributed systems has been studied at SICS for the last two years. Our main focus has been the development of a delegation logic which is based on the idea of delegation as the explicityet constrained creation of new privileges. The Amanda project is the common denominator for a small collection of projects involving Microsoft Research, Cambridge, the Swedish Defence Material Agency, SaabTech Systems, and SICS. Over the past two years, a team of researchers have examined the problems of authorisation, delegation, and authorisation management in distributed systems. A very topical issue is the establishment of Public-Key Infrastructures (PKI) as a fundamental basis for secure interaction on the web. Whereas the establishment of PKIs at the level of closed systems - individual organisations - is now to a large extent routine, significant problems remain to be solved at the level of open systems, slowing down the wider adoption of PKI in industry. Important factors are concerns related to certificate interoperability, certificate management, authorisation (roles and delegation) and organisational structure. Important as it is however, in many Internet applications a strong authentication mechanism is not in itself the goal. Authentication is needed to support other functions such as authorisation and auditing. The development of authorisation and auditing mechanisms for distributed systems is currently a very active field of research. Traditional authorisation mechanisms are based on the Access Control List (ACL) model. The ACL model was originally designed for access control decisions in closed systems, and requires that a server know in advance the identities and the permissions of its clients. Such information is recorded in an ACL that is centrally administered. However the ACL model is fraught with problems, in particular as systems scale up and become deployed in increasingly open contexts. One set of problems concerns management, relations to organisational structure and the ability to easily adapt to changes on both individual and group levels. Moreover, in open systems, a server may not know who is the next potential client. Therefore solutions based on the ACL model are not suitable for authorisation mechanisms in Internet applications, and there is a need for a more generic and common framework for authorisation and auditing in open distributed systems. The research field of 'trust management' provides the seed for such a model. In trust management the core aspect of authorisation is to answer the following question: Does the set of credentials C prove that the request r complies with the set of local policies P? The local policies are the policies of a server that controls access to some resources, and a client provides - directly or indirectly - some credentials to support its request. These credentials will typically take the form of attribute certificates, digitally signed by trusted parties or empowered authorities. A good delegation logic is a key component in such a framework, since delegation is the central mechanism by which administrative tasks and procedures are broken down into manageable parts. It is also in our opinion crucially important that a clear separation be made between administrative and executive powers. It is very easy to conceive of situations where a power to manage some administrative attributes of a given resource should be granted, but direct access to that resource should be denied. An example is outsourced management. The main focus of the work at SICS has been the development of a delegation logic which is based on the idea of delegation as the explicit yet constrained creation of new privileges. We have examined the basic principles of such a model, considered the problem of revocation in this context, and produced a number of prototype implementations including adaptations to the ongoing work on SPKI/SDSI at IETF. Links: Please contact: |
