This is a large draft technical report
Architecture for Authorization for Distributed Applications and Groups.
Intent is to make security usable.
Will be implemented in Windows NT
Make distributed authorization easy.
Share policy information
4. Design Overview
4.1 How Policies are Implemented
Figure 1, page 15.
Security Administrator creates English policy.
Enters it through Visual Policy Builder
VPB entries translated into Authorization Language (text file)
AL files checked for correctness / consistency by AL translator
AL translator sends commands to Authorization Database Server
which updates the User Policy Database
UPD used for viewing, but translated to low-level
Security Policy Database, which is used for actual authorization
4.2 How policies are enforced
One UPD per "cell".
UPD referenced through ADS.
ADS translates UPD to SPD.
SPD used by Authorization Engine. AE currently part of ADS.
Engine invoked by Adage authorization interface. Request
has principal, target, action. Engine compares with SPD.
II. User Level Design
6. Trust Model
ADAGE uses identity & attribute information from external
authentication authorities in authorization decisions.
"trust metrics" determine how external authorities are
known and how the information they provide is trusted.
This determines which Adage authorization policies the
information may be used in.
6.1 How are Authentication Authorities Recognized?
Each cell has at least one "local" authentication
authority. Cell works with it directly with proper
protocol (like DCE or Kerberos). Local authority
vouches for Adage to external users and applications.
Adage translates information from local authentication
authorities about "principals" into "actor attributes".
Such authorities have been "introduced" to Adage.
Non-local authorities are introduced by SA or by "referrals"
from other trustworthy authorities.
6.2 Do I trust you?
Cell may trust authentication authority based on several
* quality of software / techniques
* security of host OS
* competence of security manager
* quality of users
No mention of how this is factored in.
6.3 How much trust do I have in you?
Trust modelled from maximum trust (local) to maximum distrust
(hostile). Zero point indicates no knowledge.
6.4 What do I trust you for?
External authentication authorities may provide:
* attribute information about principals, possibly narrowed
down into particular sets of attributes or principals
(depending on trust).
* identity information similarly
* nothing (without proper trust)
* referrals of other authentication authorities
6.5 How do I restrict your input to decisions?
Trust model allows different classes of authentication authorities
to provide or be denied providing information about particular
classes of policies, targets, and actions.
6.6 How do I meet new authentication authorities?
Introduced by SA or by referral
Referrals by chain of Adage cells to the authority.
Trust by local cell of external authority based on local's
trust of external cell, and external cell's trust of the authority.
Anything can be overridden by SA.
6.7 Trust metrics
Principals inherit trustworthiness from their authority.
6.7.1 Citizenship metric (base trust)
Assigned to authority and its principals.
2 foreign -- principals can't be SA
1 tourist -- limited access, general authenticated population
0 alien -- unknown, unauthenticated
-1 suspect -- known, possibly hostile or tainted referral path
-2 enemy -- known hostile, denied all access
220.127.116.11 Length of disuse
Base trust level degraded at each level:
Fresh: 0-7 days
Recent: 8-30 days
Mature: 31-90 days
Old: 91-180 days
Expired: > 180, level set to alien
18.104.22.168 Quantity of denials
Measured over one hour.
Base trust value decremented each time level changes:
6.7.2 Trusted content
Limit the scope of information accepted by cell from a particular
authentication authority. Possible categories:
* Identity information (about principals from that
* Attribute information, possibly restricted to certain
6.7.3 Scope of trust
Which decisions can a particular authority or (citizenship)
class affect? Set in a rule:
<AuthorityType AccessType Context>
AuthorityType : Name of authority or citizenship class
AccessType: positive or negative
Context: specified sets of policies, attributes, or actions
6.7.4 Referral Chains Metrics
22.214.171.124 Length of chain of referral
Weakens base trust:
Close: 0-2 hops, 0
Distant: 3-4 hops, -1
Remote: 5-6 hops, -2
Too Far: >6 hops, unusable
126.96.36.199 Quality of Link
How much a link is trusted to refer others. Calculated like
base trust. Paper is unclear about who is trusting the link:
the cell getting the chain, or the next link in the chain.
188.8.131.52 Number of chains
Must be completely distinct chains, no overlaps. More is
6.8 Trust computation
6.8.1 Computing trust in external authorities
Set by SA or calculated from referral chain.
Chain cleaned up first, then trustworthiness of each node
Resulting trust level determines how information from
that authority is used.
Conflicts may be generated automatically. Adage disables
6.8.2 Calculating Base Trust from referrals
Each chain is trusted at the level of the lowest link
and possibly lowered to max trust at that distance.
Trust levels of chains are calculated by algorithm on
7 Adage Visual Policy Builder GUI
Only prototyped so far
Policies made of three elements, called "building blocks":
actors, targets and regulations
Elements can be grouped arbitrarily (not necessarily homogeneously)
Buildings blocks have "attributes" associated with them
7.2 Authentication Authorities
External authentication authority principals turned into actors.
Adage synchronizes with authorities when needed.
Same as "subjects" or "principals".
Group of actors is a "team".
Single or multiple authentication identity (multiple accounts).
Identified by name field (attribute?)
Built-in attributes: label, label set, group-membership,
secrecy level, integrity level
GUI provides dialog box for manipulating actor attributes
7.3.1 Actor templates
SA can refer to all actors of a particular type
Thing that an actor requests access to.
Group of targets called "collection".
Similar set of built-in attributes, dialog box, templates
7.5 Applications and Actions
7.5.1 Registered Actions
Applications that use Adage for authorization register with
the GUI to indicate what actions they want to use on which
Specify actions that actors are allowed to take on targets.
Group of actions called a "manual"
Regulations may have simple constraints using a single
relational operator (each) and may be templated.
Sets of various policy pieces.
Groups may contain groups, and members of the contained
group are made members of the containing group.
Policy is a group containing at leaste one actor, target,
and regulation (or their respective templates).
Default policy can be defined for requests with otherwise
7.9 Advanced features
7.9.2 Historical dependencies
Actor has (not) done an action on a target
Useful for Chinese Wall policy
7.9.3 Multi-Person Policies
Fuzzy, but some actions may require more than one actor
7.9.4 Policies involving different types of actors
GUI provides way to specify multiple actors or actor templates
that are allowed to do something. Sort of an on-the-fly
group of actors.
7.9.5 Delegated Identies
Supports delegation of authority from one principal to
another, not clear how.
7.9.6 Group (really TEAM) Constraints
Can avoid team overlap, avoid a user using more than one
at a time, and set the maximum cardinality of a team.
7.10 Function Summary
Functions available through GUI
8. Adage Authorization Language
Textual representation of stuff from the Visual Policy Builder
Extension to Tcl
8.1 Declaring objects
By type and name. Declared by keyword for that kind of object,
the name of the object, then a list of attributes for that
object. Many attributes are sets of lower-level objects.
Same as available through GUI, plus "history", which specifies
what actions have happened in relation to the object.
Made with wildcards
Apps register via an AL (Tcl) script
Can have attributes mentioned in the GUI section, plus
sets of name/value pairs. Text is not clear on what is
done with those pairs.
Same attributes as with GUI
Same attributes as with GUI, but constraints may use all logical
operators as well instead of just AND'ing them.
Sets of actors & their templates
As with GUI, with the team constraints.
Sets of targets & their templates
As with GUI.
Sets of regulations & their templates
As with GUI. Regulations on same action are AND'ed together.
Groups of actions.
Also groups of actions, used to enforce least privilege
"role-team" attribute indicates who can take actions within a role.
8.1.12 Policy pieces
Not clear. Give additional semantics to actors and teams.
As with GUI. One attribute indicates if policy is active or
latent. Other attributes are sets (by type) of the things
that can be in the policy.
8.1.14 Authentication authorities
Indicates how the external authority data translates into Adage
objects and attributes
8.2 Operations on objects
Can add, remove, or modify objects in cells or attributes
Can list information in the cell
PolicyFor command can query whether particular action is allowed
by particular actor on particular target. Specifying two of the triple
returns list of names of the third entity allowed.
10. User policy database
User-level abstractions from VPB and AL.
When it is, various consistency checks will be done on the data.
Conflicts result in denials of access.
III. Protection Mechanism Design
11. Adage Protection Mechanisms
Based on protection matrix and on role-based access control.
Rules express complex authorization policies based on properties
of roles, buject, and object
You got history, too.
11.2 Terminology and Name Space
11.2.1 Terms for basic entities
VPB actors may have multiple "principals" in the protection
target = target
action = action
set of "rules" implements a VPB regulation
Homogeneous sets. Flat, non-hierarchical group structure.
11.2.3 Name Space
VPB/AL is hierarchical. Mechanisms is flat, with a flattening
name translation scheme (not described).
11.3 Basic Entities
active entities that access targets. User, machine, or application
program or operation specific to a program
Actions must be part of a generic action when registered.
Generic actions are read, write, execute, append, delete, copy
11.4 Groups: Teams, Collections, and Action Sets
Role contains three groups: team, collection, and action set
By default, within a role, any role principal may perform any
role action on any role target. Can be modified by
Tag on one of the three basic Agadge entities. Has
confidentiality level, integrity level, and category names.
Used in rules to determine if access should be given.
11.6.2 Principal Labels
"Floating label" on a principal indicates its current level
of access. Starts empty. Filled in as principal performs
access. Changes if role changes.
"Label closure" indicates total range of floating label
for a given principal for a given policy.
User shown current label status.
User may be required to acknowledge label status changes
to avoid trojans.
11.6.3 Target labels
Assigned by SA or by inheritance rules
11.6.4 Action Labels
Assigned by SA. Indicate in what roles they are used.
11.6.5 Label Inheritance
Labels inherited from parent. Not obvious what a parent is.
Indicates what principal has performed what action on what target.
Implemented as a 3D bit matrix.
Generalization of ACL.
Contain scopes and constraints
Scopes indicate teams, set of actions, and collection to
which the rule applies.
Statement about relationship between principal's label and
target's label, and principal's history with the target.
Various label characteristic comparisons and logical operations
available (page 80).
11.9 Separation of duty and role activation
Normally, any principal in a role may assume it at any time.
Mutual exclusion and history are more complex.
11.9.1 Separation of duty
Two or more people may be responsible for the completion
of a task.
Variations based on when and on which objects principals
may act in different roles.
11.9.2 Role activation
Role activated by performing action permitted by that role.
11.9.3 Role de-activation
Happens when user explicitly deactivates.
11.9.4 Label float
Automatic label changes only increase levels.
11.9.5 Cardinality Rules
Limit the number of principals active in a a role.
11.10 An example
11.11 How access is computed
11.11.1 Decision Input
principal's label closure and floating label, action's label,
and target's label.
11.11.2 Rule Selection
rules selected for which the scopes in the appropriate
11.11.3 Role activation
Role containing appropriate rule activated if it activation
11.11.4 Role reduction
Attempt to reduce set of roles about to be activated.
11.11.5 Rule evaluation
Evaluate constraints for each rule, & deny access if any fail.
Update label if now roles require.
11.11.6 Label computation
Updating of float label based on given algorithm.
12. Authorization Language Translation
IV Low Level Design
Adage is in C++
14 Supporting Classes and Data Structures
15 Authorization Engine.
Description of a nifty C++ class.
16 Authorization database server
17 User policy database
18 Security Policy Database
V Case studies