OASIS - An Open Architecture for Secure Interworking Services
An emerging requirement is for applications and distributed services to cooperate or inter-operate. Existing mechanisms are able to hide the heterogeneity of host operating systems and abstract the issues of distribution and object location.
However, in order for systems to inter-operate securely there must also be mechanisms to hide differences in security policies, or at least to support negotiation between them.
Other proposals for the interworking of security mechanisms have focussed on the enforcement of access policy at the expense of flexibility of expression of policy. This work describes a new architectural approach to security. The key idea is that a process is the universal client entity; a process may act on behalf of an identified individual as in traditional security schemes.
More generally, a process may adopt an application - specific name or role, and this is used as the basis for authentication in OASIS. A service may then be written in terms of general categories of clients, decoupled from the mechanisms used to specify and enforce access control policy.
This approach allows great flexibility when integrating a number of services, and reduces the mismatch of policies common in heterogeneous systems. In addition, OASIS services may be integrated with alternative authentication and access control schemes, providing a truly open architecture.
A flexible security definition is meaningless if not backed by a robust and efficient implementation. OASIS has been fully implemented, and is inherently distributed and scalable. OASIS is unique in supporting rapid and selective revocation of privileges which may cascade between services and organisations.
The origin of OASIS was in the principal-specific, capability-based access control designed for our Multi-Service Storage Architecture (MSSA)
Richard Hayton's thesis work produced OASIS. In summary:
- OASIS servers name their clients in terms of roles. OASIS scales well because access rights are associated with roles rather than individual principals;
- Services specify policy for role-entry in RDL (Role Definition Language);
- To use a service, clients present credentials for entering a named role. The service checks the credentials against the RDL policy specification. RDL is a formal logic based on Horn clauses so a service proves the correctness of its clients' credentials;
- If successful, the client is issued a role membership certificate (RMC). This is effectively a dynamically maintained, principal-specific capability;
- The client presents the RMC with each service invocation;
- Services may be OASIS-aware and require, but not issue, RMCs.
Interdependence of OASIS and Events
OASIS is built above the Cambridge Event Architecture. Using event notification, an RMC may be revoked immediately should a role entry condition become false.
Access control is needed on registration of interest in events and on notification; that is all services may be OASIS-aware services and require RMCs on event registration.
Deployment and Evaluation
An application area we are considering is access control for digital libraries in a multi-campus university.
Professor John Hine of the University of Victoria, Wellington, New Zealand spent 1999 with us as an EPSRC Visiting Fellow.
An EPSRC grant (GR/M75686) has been awarded under the Distributed Information Management programme. OASIS access control: implementation and evaluation. This grant runs from 1999 to 2002 and plans to investigate the deployment of OASIS. An application under investigation is access control for electronic health records.
The following members of the OPERA group are involved in this project:
- Jean Bacon
- Ken Moody
- Walt Yao, graduate student
- John Hine, Visiting Research Fellow, 1999
- Richard Hayton, CL PhD and RA until 1996, now at Citrix, Cambridge