We describe a n a r chitecture for secure, independent, interworking services Oasis. Each service i s made responsible for the classi cation of its clients into named roles, using a formal logic to specify precise conditions for entering each role. A client becomes authenticated by presenting credentials to a service that enable the service to prove that the client conforms to its policy for entry to a particular role. During authentication a data structure i s created that embodies the proof.An authenticated client is issued a r ole membership certi cate RMC for its subsequent use with that service. An RMC is an encryption-protected capability which includes the role name, the identity of the principal to which it was issued and a reference to the issuing service. A p r oof rule of one service may refer to an authenticated user of another; that is, an RMC issued by one service may be r equired a s a c r edential during authentication by another. A dynamic proof tree may thus be built which exhibits amongst other things the trust relationships between the services which the client has entered.The rst part of the paper shows how a service may de ne a set of proof rules Horn clauses that specify who may use it and in what way. Delegation of rights may be expressed naturally within these rules.The second part of the paper presents the design details of the system. Associated with each RMC issued by a service, the service keeps a credential record CR. The CR indicates the predicates against which the RMC was issued and lists all other services which have issued RMCs to this principal based on this CR. If one of these predicates becomes false, the local RMC is immediately invalidated. Event technology is used to achieve rapid revocation of the dependent RMCs issued by other services; any portion of a proof tree which is based on this predicate collapses.The system is inherently decentralised and has a tuneable reaction to network or server failure which allows services to make appropriate decisions when authorization or revocation information is unavailable.A prototype system has been implemented and tested.

No abstract

There is a developing need for applications and distributed services to cooperate or inter-operate.Current mechanisms can 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 ways 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 service-specific 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 that is 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. In this paper we describe the general approach then concentrate on revocation, where security designs are most often criticised. Oasis is unique in supporting the rapid and selective revocation of privileges which can cascade between services and organisations. • n 1 IntroductloIn a widely distributed environment there will be many different organisations. If users and services in these organisations are to interwork, there must be standard mechanisms for the specification and enforcement of access control policies. When a request is made of a service, that service must decide on some basis whether to perform the request. The flexibility of an access control architecture hinges on the amount of information available to the service when making this decision; if no information is provided then no useful distinction can be made between requests. Traditional approaches to security are closed in the sense that the information available is strictly limited and defined by a generic security architecture. Ideally, we should be able to develop applications and services in terms of service-specific categories of clients. For example a Meeting application could be developed with client categories Chair, Speaker and Member. The conditions under which a particular user may assume one of these roles are a feature of the environment in which the application is used, not a feature of the application itself.Such a scheme would provide a flexible mechanism to allow the integration of separately developed...

No abstract

No abstract