Access Control in MMX Framework is impemented based on principles of Role Based Access Control as defined in standard specification ANSI INCITS 359-2004, Role Based Access Control (http://www.incits.org/). To be more precise, the implementation is based on Hierarchical RBAC, adding support for Role hierarchies to Core RBAC component. Details about RBAC in general and in detail can be found here: http://csrc.nist.gov/groups/SNS/rbac/.

Quoting from the abovementioned document: "Core RBAC includes sets of five basic data elements called users (USERS), roles (ROLES), objects (OBS), operations (OPS), and permissions (PRMS). The RBAC model as a whole is fundamentally defined in terms of individual users being assigned to roles and permissions being assigned to roles. As such, a role is a means for naming many-to-many relationships among individual users and permissions.

A user is defined as a human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this document for simplicity reasons. A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. Permission is an approval to perform an operation on one or more RBAC protected objects. An operation is an executable image of a program, which upon invocation executes some function for the user. The types of operations and objects that RBAC controls are dependent on the type of system in which it will be implemented. 

Consistent with earlier models of access control an object is an entity that contains or receives information. The set of objects covered by RBAC includes all of the objects listed in the permissions that are assigned to roles."

 

Implementation. MMX Framework offers perfect means for implementing RBAC classes and associations as part of Core MMX: RBAC Metamodel constitutes simply another metamodel on MMX M2 level. As it is often the case with RBAC implementations, the possible values of Permission Type are enumerated as ALLOW (+), DENY (-) and (optionally) NOT_KNOWN (?) so both 'restriction based' and 'permission based' access control (and even a mix of them) is possible.

It is assumed that authentication of users is typically not a part of a metadata application and an external Active Directory service is providing the verified identities (possibly with roles) so Users and Roles contain merely references to information in AD. Semantics of the Operations is not defined in RBAC (see the quote above) and is the role of an application to define and implement. Therefore it is up to an application designer to decide the level of abstractness of the operations he/she would like to see tracked by Access Control, and how to interpret those Operations in application code.     

Role hierarchies define an inheritance relation among roles. As stated in ANSI INCITS 359-2004, "The Hierarchical RBAC component adds relations for supporting role hierarchies. A hierarchy is mathematically a partial order defining a seniority relation between roles, whereby senor roles acquire the permissions of their juniors and junior roles acquire users of their seniors." In MMX terms, a role in the role 'tree' has all the permissions of the roles 'below', and all the users of the roles 'above' itself.
 
In addition to Role hierarchies, MMX Framework RBAC implementation treats Access Control Objects as hierarchies as well enabling an application to exploit the hierarchy management functionality that is part of the Framework. So it is sufficient to denote a root or subroot of a class hierarchy as an Access Control Object to have the whole hierarchy of classes assigned to a Permission or a Role. This enables an application to build an Acces Control List easily with full support from Metadata API, part of MMX Framework Access Layer. 
 
Access Control Object references a metamodel class (either in the role of the root of a hierarchy, or denoting a specific class directly) with a property (set of properties). Currently the list of properties for this purpose is (but not limited to) as follows:
 
- RootReference (root of a hierarchy is denoted by the class reference);
 
- RootModel/RootObjectType (root of a hierarchy is denoted by a combination of a metamodel name and a class name that uniquely identifies the root class);
 
- Reference (class reference identifies the class directly); 
 
- Model/ObjectType (combination of a metamodel name and a class name identify the class directly).
 
RootReference, RootMode, RootObjectType and Model have multiplicity of 1 while Reference and ObjectType properties can have an arbitrary number of instances, therefore a list of classes can be identified as a single Access Control Object.