MMX Framework has built-in Access Control support as part of its Core Metamodel (http://mmxframework.org/post/2009/06/30/Access-Control-Implementation-in-MMX-Framework.aspx) based on RBAC System and Administrative Functional Specification (see ANSI INCITS 359-2004, Role Based Access Control). As stated in this document, "The RBAC Functional specification specifies administrative operations for the creation and maintenance of RBAC element sets and relations; administrative review functions for performing administrative queries; and system functions for creating and managing RBAC attributes on user sessions and making access control decisions."

The following set of functions is defined on Core/Hierarchical RBAC level. 

Administrative Commands (see Note 1):

AddUser(user)
DeleteUser(user)
AddRole(role)
DeleteRole(role)
AssignUser(user, role)
DeassignUser(user, role)
GrantPermission(object, operation, role)
RevokePermission(operation, object, role)
AddInheritance(r_asc, r_desc)
DeleteInheritance(r_asc, r_desc)
AddAscendant(r_asc, r_desc)
AddDescendant(r_asc, r_desc)

System Functions (see Note 2):

CreateSession(user, session)
DeleteSession(user, session)
AddActiveRole(user, session, role)
DropActiveRole(user, session, role)
CheckAccess(session, operation, object): BOOLEAN

Review Functions:

AuthorizedUsers(role): USERS
AuthorizedRoles(user): ROLES
RolePermissions(role): PERMS
UserPermissions(user): PERMS
RoleOperationsOnObject(role, obj): OPS
UserOperationsOnObject(user, obj): OPS
SessionRoles(session): ROLES (see Note 2)
SessionPermissions(session): PERMS (see Note 2)

MMX Framework RBAC API implements AuthorizedUsers, AuthorizedRoles, RolePermissions, UserPermissions, RoleOperationsOnObject and UserOperationsOnObject as Table Functions receiving MMX object identifiers of a proper type as parameter(s) and returning tables (rowsets) as values. Oracle implementation is contained in package MMXAC.

An additional function, object_types(obj) that is not part of the RBAC Functional Specification converts an RBAC object into a list of MMX object types (classes) denoted by a single RBAC object identifying an MMX object type or object type hierarchy. 

Note 1: The functionality of Administrative Commands is provided by MMX Administrative UI application (eg. MMX Metadata Navigator).

Note 2: RBAC Sessions are temporary in nature and are not supported by MMX Framework.  

Here's the implementation details on Oracle platform (package header) for the record: 

FUNCTION authorized_users (role_id IN MD_OBJECT.object_id%TYPE)
RETURN user_table PIPELINED;

FUNCTION authorized_roles (user_id IN MD_OBJECT.object_id%TYPE)
RETURN role_table PIPELINED;

FUNCTION role_permissions (role_id IN MD_OBJECT.object_id%TYPE)
RETURN perm_table PIPELINED;

FUNCTION user_permissions (user_id IN MD_OBJECT.object_id%TYPE)
RETURN perm_table PIPELINED;

FUNCTION role_operations_on_object (role_id IN MD_OBJECT.object_id%TYPE, obj_id IN MD_OBJECT.object_id%TYPE)
RETURN op_table PIPELINED;

FUNCTION user_operations_on_object (user_id IN MD_OBJECT.object_id%TYPE, obj_id IN MD_OBJECT.object_id%TYPE)
RETURN op_table PIPELINED;

Note 3. authorized_users, authorized_roles, role_permissions and user_permissions without parameter return the full list of their respective RBAC class instances.

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.