Information Technology Reference
In-Depth Information
is often important for determining access, and can be even more important for
accountability. However, requiring subject identity as a mandatory attribute
precludes anonymous services. Examples of subject attributes include identities,
group names, roles, memberships, security clearance, pre-paid credits, account
balance, capability lists, etc. Examples of object attributes are security labels,
ownerships, classes, access control lists, etc. In e-commerce applications a price-
list could be an object attribute, e.g., a particular e-book may stipulate a $10
price for a 'read' right and a $15 price for a 'print' right. The general concept
of attribute-based access control is commonplace in the access control literature
and as such this aspect of ABC builds upon familiar concepts.
A significant innovation in ABC is that subject and object attributes can be
mutable.
Mutable attributes
are changed as a consequence of access, whereas
immutable attributes can be changed only by administrative action. Policies
requiring limits on the number of accesses by a subject or reduction of account
balance based on access can be easily specified using mutable attributes. More
generally, various kinds of consumable authorizations can be modelled in this
manner. High watermark policies on subject clearance and Chinese Walls can
also be enforced in this way. The introduction of mutable attributes is a critical
differentiator of ABC relative to most proposals for enhanced models for access
control.
Authorizations, obligations and conditions are decision factors employed by
the usage (or access) decision functions to determine whether a subject should
be allowed to access an object with a particular right.
Authorizations
are
based on subject and object attributes and the specific right in question. Unlike
prior models ABC explicitly recognizes that each access has a finite duration.
Authorization is usually required prior to the access, but in addition it is possible
to require ongoing authorization during the access, e.g., a certificate revocation
list (CRL) can be periodically checked while the access is in progress. If the
relevant certificate appears on the CRL access can be terminated. Authorizations
may require updates on subject and/or object attributes. These updates can be
either pre, ongoing, or post. The high watermark policy requires update of the
subject's clearance prior to access. Metered usage payment requires updates after
the usage has ended to calculate current usage time. Using pre-paid credits for
time-based metering requires periodic updates of the remaining credits while
usage is in progress, with possible termination in case of overuse.
Obligations
are requirements that a subject must perform before (pre) or
during (ongoing) access. An example of a pre-obligation is the requirement that
a user must provide some contact and personal information before accessing a
company's white paper. The requirement that a user has to keep certain adver-
tising windows open while he is logged into some service, is an example of an
ongoing obligation. Subject and/or object attributes can be used to decide what
kind of obligations are required for access approval. The exercise of obligations
may update mutable attributes. These updates can affect current or future usage
decisions.
