Active Capability Based Authorization Framework
One of the problems we faced in building security systems for
mobile and remote collaborative systems is the unexpressiveness of
delegation restrictions. In the project we tackled the problem
by proposing a new security authorization model based on
the recent innovations on type safe scripting language, extendible
systems software, and software protection. The basic idea is to
augment the
conventional capability-based security and protection model with user-supplied
script. The principles behind this design are:
it provides a unified framework for incorporating different security
models
it supports delegation and revocation in dynamic communication
environments like mobile computing
it decouples high level security functions, such as delegation
and accesscontrol, from underlying facilities,
such as authentication and encryption.
it allows application to define its own security policy in a descriptive
way
it provides a minimum policy-free core of security functions which can
be implemented efficiently
it enables extendibility, reconfigurability and adaptability
by keeping the complexity
of application specific security policies in user-level scripts
Architecture
Traditionally security systems often use an access matrix to model
access control policies. Each column of an access
matrix represents a protected object and each row corresponds to a
principal who wants to access that object. Each matrix entry defines
the access rights the potential principal has on that object.
The limitation of this model is that it can only model static access
control policies. Our active capability model goes beyond this
limitation by replacing passive access rights with executable scripts.
In this way we can use this augmented access matrix as a general model to unify
the modeling of
many different policies and services dynamically and flexibly.
Active Capability
An Active capability is an active object which carries out security
functions for protecting and controlling access to the object(s) it is
associated with. In our design it is realized as a piece of unforgeable
script so that it can reside in user space and be freely passed
around.
When a principal wants to access an object, it needs to present the capability
and the desired operations.
It is essential that the system can safely run the script in a domain
different from the one in which the script originated.
Thus we advocate the use of a safe language such as Java which
is type safe and can be checked for security violations.
Another benefit of using Java is that we can construct active
capabilities in an object-oriented fashion. For example capabilities with
delegation support
can reuse the authentication code through subclassing the authenticated
capabilities. Also, we may use metaobjects to describe the internal structure
and validation procedures of those capabilities.
To reduce the capability's size for the common cases, the system can provide
standard capability bases and a user can reference the scripts in the bases
instead of providing copies of the scripts.
Security Agent
A security agent defines the low level security protocols used between
active capabilities and security managers including
authentication and
encryption methods. An agent runs in a security manager as part of
its runtime systems. Since it is written in Java script, it can be easily
distributed and loaded/unloaded into security managers.
Security Manager
A security manager mainly consists of a Java interpreter and a security
runtime system.
%The java interpreter also uses active capabilities to control accesses.
The responsibility of a security manager is to create and
validate active capabilities. It provides security management to
conventional
name servers by maintaining security information about objects(servers)
such as public/private keys, passwords and identity certificates.
Each security manager provides a minimum set of security services and
most functionality is extended through run-time loading in
security agents and active capabilities.
Object Manager
Object managers can be persistent objects, databases, kernel services
or libraries. Conceptually, they mainly consist of two kinds, static ones
like persistent objects or dynamic ones like object factories.
In the active capability model, an object manager creates and
manages objects whose access rights are defined and interpreted
by the manager.
Whenever a client wants to access an object it passes the desired
operation to the capability associated with this object. The security manager
dispatches a compatible security agent to
verify the capability and provide appropriate runtime environment for
the capability to determine if this access will be granted or not. If it
is granted, the security agent sends a message to an object manager
who manages
the desired object, including information about the identifier of
the object and operations.
Delegation
To demonstrate the feasibility of our new authorization model and
the generality of our delegation scheme, we reimplemented the delegation
protocol described in the previous section. We constructed delegatable
capabilities which accepts delegate operation and generates new capabilities
for delegates. We will show how the active capability model can unify
the existing delegation models in the rest of this section.
Centralized Model
Many existing delegation architectures use a centralized
authentication server to provide delegation services. Because of the
different delegation requirements, they often devise several different
delegation mechanisms in one system. However with the active
capability model, the diversity of delegation mechanisms is
encapsulated in an active capability itself.
Distributed Model
The major disadvantage of the centralized approach is that the
delegation server can be a serious bottleneck to the entire system
even though some applications don't require any security function at all.
So some people have proposed several distributed delegation models
Service-Based Delegation
In the past we designed a customizable
framework supporting frequent delegation and revocation for Choices.
As described in the previous section,
we performed delegation on a per-service basis, i.e. delegation attributes
are maintained and interpreted solely by the service being delegated.
Like other static access control list approaches, this
model is inadequate for specifying dynamic and fine-grain delegation
restrictions.
In the active capability model, this delegation
model active capabilities interact
with the service providers whenever users want to access the service via
the active capabilities.
Because of the descriptiveness of the
Java script language, delegation capabilities can impose arbitrary
restrictions.
{Client-Based Delegation}
One of the most distinctive features of the active capability model
is that it can support client-based delegation, with which the delegation
service can be construct in a fully distributed way. The essential idea
is that with the property of some asymmetric encryptions like the RSA,
active capabilities can be verified and authorized
locally. One of the ways to implement this is to let each principle
involved in a delegation process give the capability a certificate signed
by its private key. Therefore the security agent or event the active
capability itself can verity its validity. It also makes
cascading delegation very simple. As for revocation, depending what the
applications requirement is, different revocation mechanisms can be
realized by defining a application-specific authentication and
authorization protocol between active capabilities} and security
agents}.
Implementation
The first step we did to implement the active capability model was to
to integrate Kerberos into the Java Virtual Machine to make
the Kerberos-based authentication and encryption facilities available
to Java applications and applets.
To allow plug-and-play authentication protocols and encryption
algorithms, we adopted GSS API as the service programming interface (SPI).
This software package, called JGSS has been available for public evaluation since
early 1996 at
http://choices.uiuc.edu/Security . With this
JGSS package we prototyped the active capability concept using
the centralized access control list (ACL) as its implementation scheme.
The active capability based authorization framework is also able
to support any combination of authorization protocols between centralized
access control lists to decentralized capabilities.
We demonstrated the effectiveness of active capabilities
by reimplementing our delegation protocol for mobile computers
using this prototype, where the services use active capabilities to
specify delegation rights and restrictions.
Please send comments and suggestions to Tin Qian
Last modified: Tue Jul 1 00:15:58 CDT