[xacml] Multiple subjects semantics

[Anne Anderson <Anne.Anderson@Sun.com>]

The attached document is in response to my action item from the
22 July 2002 Schema Subcommittee to produce a description of the
semantics of multiple subjects in an XACML request.

This is a draft, and comments are welcome.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Title:   Multiple Subjects in XACML Requests and Policies
Author:  Anne H. Anderson
Version: %I%, %E% (yy/mm/dd)
Source:  %P%

WHY MULTIPLE SUBJECTS?

An Access Request is always made in the context of multiple
"subjects", each playing a different role in making the request.

It is the executing code that makes an actual access request, and
this request may be more or less connected to any explicit
request that the user associated with the executing thread has
made.  We sometimes think of the "userID under which the
requesting thread was executing" as the only Subject, but that is
a mistake for access control purposes.  This "real" Subject may
be executing code containing a Trojan Horse.  The Trojan Horse
may make an access request for confidential data, hiding under
the identity of the userId, and then transmit this data to an
unauthorized user.  The "userId" Subject is completely unaware
that this access request is being made, and is unable to prevent
it.  In another case, the request may have been generated by the
OS kernel as part of some periodic maintenance operation.  The
identity of the "user" who initially booted the OS kernel is not
really the important factor in deciding to grant access.
Requests for database access often come from corporate
applications that have been written to allow only "safe" types of
requests.  The policy needs to ensure that the request came from
the corporate application code and not directly from a particular
user.

Security can be vastly improved if access policies can take into
account the full constellation of "subjects" from which a request
is received.  For example, if the requesting code was executing
on a machine whose DNS name is known to be inside the corporate
firewall, that request may be granted higher privileges than a
request coming from outside the corporate firewall.  A request
coming from code that was signed by a trusted authority may be
given higher privileges than a request from unsigned code.  A
request coming from code that was downloaded from the corporate
web site may be trusted more than code downloaded from an unknown
site in Korea.

RELATIONSHIPS BETWEEN MULTIPLE SUBJECTS

Abadi, Burrows, Lampson, and Plotkin, in "A Calculus for Access
Control in Distributed Systems", present a formal method for
describing the relationships between various subjects, using
various types of delegation.  In their method, the subjects in a
typical access request might be expressed as

   ExecutingMachine(D) quoting (CodeSourceSigner(C) asserts
   CodeSource(B) is B) speakingFor ExecutingUser(A)

Syntax:

  Principal ::= (name, type)
             |  (Principal and Principal)
             |  (Principal quoting Principal)
             |  (Principal speakingOnBehalfOf Principal)
             |  (Principal asserts Principal)

Structure:

                  Principal
                    /  \
                  /      \
                /          \
              /              \
            /                  \
       SimplePrincipal      ForPrincipal
                                /  \    \
                              /      \     \
                            /          \      \
                          /              \       \
                        /                  \        \
                   BehalfOf             Quoting    Asserts

Then the policy can make statements such as "allow access if
ExecutingMachine(D) quoting ExecutingUser(A)", rather than
treating all request Subjects as undifferentiated identities.

A single entity may have multiple Subject Identifiers, and
various attributes may be associated with the various Subject
Identifiers.

We may eventually support a "complexSubject" element that can
express such relationships.

ROLES OF MULTIPLE SUBJECTS

Relationships between multiple subjects may be important,
particularly for establishing trust, but another factor is the
role that a particular subject plays in making the request.  A
major existing body of access control policies, for J2SE
applications, uses this concept.

These "roles" are not general roles, but "roles in making the
access request".  We know accesses come from particular machine
identities, from particular executable code sources (which may be
signed by one or more entities, and may have been loaded and
verified by a trusted entity), running under one (or more) user
or server identities, etc.

XACML supports expression of this concept of "role in making the
access request" using the "SubjectCategory" attribute.  The
default for this attribute is "AccessSubject", meaning the (user)
identity under which the requesting code was executing.
Particular communities of users, such as J2SE, may define other
access request subject categories to fit their view of the
request environment.

MULTIPLE SUBJECTS IN POLICIES

A policy writer expresses various constraints on access requests.
Just as the policy writer may require that an AccessSubject have
both "System Administrator" and NOT("Contractor") corporate role
attributes, the policy writer may require that the CodeSource
subject be signed by the corporate code authority and that the
ExecutingMachine subject be an IP address inside the corporate
firewall.

If a policy constraint requires that a subject with a particular
access request role be present in the Request context, then that
constraint is INDETERMINATE if the particular subject is not
available in the Request context.

If a policy writer never refers to a subject with a particular
access request role, then the presence or absence of that
particular subject in the Request has no effect on the policy
decision.

MULTIPLE SUBJECT IDENTITIES

A single subject may have multiple identities.  The
"AccessSubject", for example, may have been authenticated under
the name "Anne.Anderson@Sun.COM" and under the name "cn=Anne
H. Anderson, ou=SunLabs, o=Sun, c=us".  The "ExecutingMachine"
subject, for example, may be known as "129.149.246.180" or as
"sunmail2.sfbay.sun.com".

XACML has chosen to create a different "Subjects" element for
each subject identity.  Since attributes are issued to particular
subject identities, this allows attributes to be grouped under
the identity to which they were issued.  Thus, there may be
multiple "Subjects" elements, all of which have the same
"SubjectCategory", but which have different subject identities.
All "Subjects" elements with the same "SubjectCategory" are
viewed as describing the same entity.

If the policy writer is creating a constraint based on an
attribute of a subject category, without respect to subject
identity, then the policy can be written to view all attributes
of a given subject category together.  For example, if the
"AccessSubject" must have the corporate role "System
Administrator", regardless of the identity to which that role
attribute was issued, then the policy can say

   <subset>
       Request/Subject[@SubjectCategory="AccessSubject"]/Attribute/Role
       "System Administrator"
   </subset>