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>