[WG-UMA] Scope and Access Control in UMA (draft proposal)

Thomas Hardjono identity at hardjono.net
Thu Sep 30 16:56:05 EDT 2010


Here is a draft proposal for scope and access control in UMA.  I have
used the UMA terms intentionally (eg. User, Requestor) and avoided the
classic terms like "Object" or "Groups".  I have introduced some new
terms (like Multi-Managed), which I don't think is defined as yet in

When talking about access control I have avoided the term "Shared" (to
avoid confusion from its usage in UMA and OAuth).

We also need to answer the classic access control question: if a User
relegates 100% Full Control (over her/his resource) to a Requestor,
the Requestor essentially becomes equivalent to the User/Creator. My
solution to this problem is to define the UMA Requestor as an entity
that has Read+Write access only, but never Full Control.

Please feel free to comment or start a discussion thread.



Proposal: Scope and Access Control in UMA

(1) Definition: a User manages access control/permissions on Resources
(which reside at the Host) by using the AM.  For every resource at a
Host, the Creator (a UMA User) of that resource is the default Owner
of that resource.

(2) UMA Access Control on Resources: From an access control view, each
protected Resource in UMA is referred to as an Access Control Resource
(or Objects).

(3) Multi-managed Resources: From an access control management view,
the management of permissions on a Resource can be done by a sole User
(Sole-Managed Resource) or it can be done by multiple Users
(Multi-Managed Resources). The Creator of a Resource has to define at
moment of creation whether a resource is Multi-Managed or

Depending on the UMA implementation, a Sole-Managed resource MAY be
re-casted (downgraded) by its Creator to be a Multi-Managed resource
at a later time.

[NOTE: Sole-Managed and Multi-Managed resource is only from the
perspective of managing permissions on resources by the User/Owner. By
the argument/extension, a UMA Requestor that has Full Access to a
Resource actually becomes a member of the Multi-Managed Group for that
resource. Which is why I think only the Creator/Owner should have Full

(3) Levels of permissions: Access control is administered at the
resource/object level (by the User/Creator via the AM) by setting
different levels of access, or permissions, to resources. 

The levels defined are: (i) Full Control, (ii) Write (Modify), (iii)
Delete, (iv) Read, or (v) No Access.  By default, permissions on
objects are set to the most secure setting (namely No Access).

For UMA resources, only the Creator user has Full Control (in
particular to Delete). Other Users (if any) and UMA Requestors should
only have Write/Modify and Read Access only. The distinction between
Write/Modify and Delete is important from the audit perspective (see
auditing below).

(4) UMA metadata for access control: For each UMA resource, the
User/Creator manages the permissions on Resources by using the AM. The
AM them pushes the access control metadata for each resource to the
appropriate Host.  Following the AM-Host contract (trust framework),
the Host honors the contract by enforcing the permissions defined in
the access control metadata delivered by the AM.

The access control metadata for a resource consists of the following

      (a) Security descriptors.
          (a1) Sole-managed or Multi-Managed.
          (a2) Discretionary access control list (DACL)
          (a3) Resource audit control list (RACL)
      (b) Resource hierarchy.
      (c) User authentication type.

(4a) Security descriptors:

(4a1) Sole-managed or Multi-Managed. This tells the AM whether a
Resource has multiple Users/Managers that have more than Read-only

(4a2) Discretionary access control list (DACL): The DACL related to an
Resource identifies the Users and Multi-Managed Groups that are
assigned permissions on a UMA resource/object.  By default, a DACL is
controlled by the User that created the resource. Furthermore, each
DACL contains specific Access Control Entries (ACE) that determine the
permissible access to the User's resource/object.

For Multi-Managed Resources, the DACL lists the User-identities and
their corresponding permissions on the resource.

(4a3) Resource audit control list (RACL): The RACL identify the Users
and Multi-Managed Groups that are monitored for access to an resource
(eg. successful access or failed access). The RACL is controlled by
the User that owns/creates the object. The RACL contains access
control entries (ACEs) that determine whether or not to record a
successful/failed attempt by a User to access a object using a given

Depending on the UMA implementation, the DACL and SACL may be located
at the Host holding the User's resource. However, the instance of a
DACL or SACL must initially be created at the AM (by the User/Creator)
and then pushed to the Host (and updated regularly by the AM).

(4b) Resource Hierarchy: each Resource in UMA "inherits" ACEs from the
security descriptor located in their parent container resource.
Inheritance enables the access control information defined at a
container resource in UMA to apply to the security descriptors of any
subordinate resources, including other containers and their resources.
This eliminates the need to apply permissions each time a child
resource is created. 

(4c) User Authentication Type (UAT): This metadata defines the
type/quality of authentication required by a User to access an object
with a given permission, or for a requestor to Read an object/resource
belong to a User. 

Depending on the UMA implementation, the UAT may be located at the
Host holding the User's resource. However, the instance of a UAT must
initially be created at the AM (to match the DACL) and then pushed to
the Host (and updated regularly by the AM).


More information about the WG-UMA mailing list