mmx metadata framework
...the DNA of your data
MMX metadata framework is a lightweight implementation of OMG Metadata Object Facility built on relational database technology. MMX framework
is based on three general concepts:
Metamodel | MMX Metamodel provides a storage mechanism for various knowledge models. The data model underlying the metadata framework is more abstract in nature than metadata models in general. The model consists of only a few abstract entities... see more.
Access layer | Object oriented methods can be exploited using inheritance to derive the whole data access layer from a small set of primitives created in SQL. MMX Metadata Framework provides several diverse methods of data access to fulfill different requirements... see more.
Generic transformation | A large part of relationships between different objects in metadata model are too complex to be described through simple static relations. Instead, universal data transformation concept is put to use enabling definition of transformations, mappings and transitions of any complexity... see more.

MMX Access Control: RBAC API

July 18, 2009 21:32 by mmx

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.


 



Versioning

July 3, 2009 21:11 by marx

MMX Framework supports versioning on three different levels: data, model and metamodel. Which type of versioning is most appropriate in which case depends on the purpose and context of the specific case, requirements and scope of the application etc.

On data level, every instance (M1) level entity (object, relation or attribute) is equipped with built-in timestamp structure, version number and status indicator, combination of which has the capability to encode the history of events concerning the entity. Managing these histories - instantiating multiple versions of an object, querying for event history etc. - is the responsibility of an application or service. Data level versioning treats an object as an isolated entity and pays no attention to its properties or relationships. This is the simplest form of managing versioning information but it is sufficient in most cases as usually only the latest (current) incarnation of the entities are of interest to the consumers of metadata.

On metamodel level, the contents, structure and relationships subject to versioning process are part of the metamodel (M2) and are defined as special classes dedicated for this purpose. Sometimes these version classes can be descendants of a 'main' class, inheriting all or part of its properties, but usually they are completely independent classes 'on their own right' (eg. Statistical Activity/Statistical Activity Instance and Classification/Classification Version in Neuchâtel Terminology model). How to treat metamodel level versioning is completely up to the metamodel, how and why the versioning classes are defined and the purpose and context of the application.

Things get more interesting on model level. Maintaining versions of a model object requires keeping track of related properties and relations as well based on the context of the object. To create a version of an object an application or service has to take the following steps:

- create a copy of an object (MD_OBJECT) with new id and identical values of the attributes that do not change with the new version;

- add a suffix with consequent unique number to object name to distinguish between different versions (name[1], name [2] etc.); 

- create copies with identical values of all properties and property hierarchies (MD_PROPERTY) of the object being versioned;

- create copies of all relations (MD_RELATION) with any direction of the object being versioned. 

- add an instance of special relation type PreviousVersion (inherited from MMX Core) linking the new object instance to the previous version; 

Model level versioning does not apply in case of a class with subclasses as it is assumed that in that case versioning takes places on the lowest subclass level. 

 



Access Control Implementation in MMX Framework

June 30, 2009 10:55 by marx

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.