Extensive Access Checking

The Extensive Access Checking concept is normally used for EDMsixServer systems with multi user access to an EDMdatabase. In such multi user systems, this concept enables a very flexible and configurable access control system.

Note that there is a difference between the terms Access and Protection. Access is given to users and groups on protected objects. Protection is a fixed property that is set on the protected object it self.

Protected Objects

A protected object is an EDMdatabase object which possess a set of attributes containing object protection meta data.

Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'US:_i_ProtectedObjectAttributes(350px)'.

The attributes owner, group, administrators and access_rights_for are used to determine how the EDMuser / EDMgroup relates to the protected object (Access Role).

The attribute protection is a property that is set on the protected object it self when it is created.

There are five protected object types in the EDMdatabase

EDMdataModels
EDMdictionaryModels
EDMrepositories
EDMmethod Schemata
Archived EDMmodels

When you create protected objects, the object protection is set according to a set of default values that have been assigned to the EDMuser and EDMgroup accounts that you are logged in with. The object protection is set individually for USER, GROUP and PUBLIC access. If you are familiar with UNIX, you will probably recognize this concept. For each of the USER, GROUP and PUBLIC protections, a set of five access flags will be set or unset.

READ_ACCESS (0001)
WRITE_ACCESS (0002)
CREATE_ACCESS (0004)
EXECUTE_ACCESS (0010)
DELETE_ACCESS (0020)

The USER, GROUP and PUBLIC protection settings of a protected object are all combinations of these five access flags. They combine to a five bit binary pattern and the USER, GROUP and PUBLIC protections may therefore be represented by a decimal number ranging from 0 (No access) to 32 (Full access). The The USER, GROUP and PUBLIC protection settings a protected object is represented by a single decimal number. This number results from concatenating the USER, GROUP and PUBLIC protection settings into a single 15 bit object protection pattern;

PUBLIC_READ (0001)
PUBLIC_WRITE (0002)
PUBLIC_CREATE (0004)
PUBLIC_EXECUTE (0010)
PUBLIC_DELETE (0020)
GROUP_READ (0040)
GROUP_WRITE (0100)
GROUP_CREATE (0200)
GROUP_EXECUTE (0400)
GROUP_DELETE (01000)
OWNER_READ (02000)
OWNER_WRITE (04000)
OWNER_CREATE (010000)
OWNER_EXECUTE (020000)
OWNER_DELETE (040000)

The default protection of the DataRepository in the EDMdatabase is READ|WRITE|CREATE for all the protection settings for USER, GROUP and PUBLIC. This is represented by the bit pattern 00111 00111 00111b and is represented by its decimal value 7399.

EDMsix comes with a default value for all protected objects, but you may change these as you like. When you create new EDMusers and EDMgroups, they get their individual set of protection settings inherited from the EDMdatabase configuration parameters.

Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'US:_i_CreateUserProtection(450px)'.

Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'US:_i_CreateGroupProtection(450px)'.

As administrator, you may alter these settings for EDMusers and EDMgroups individually. That is, if you decide to alter the default protection values for a given EDMuser or EDMgroup, the protection that will be set on protected objects created by them will reflect those changes.

Granting access to protected objects by EDMusers and EDMgroups is done by controlling their Access Role. Protected objects also have meta information used to determine the type of access an EDMuser or EDMgroup shall have to the object.

Protection Hierarchy

You are probably familiar with protection of files and folders in ordinary file systems. To create a new file in in a folder, you need write access to the folder. To read a file within that folder, you need also read access to the folder. The Extensive Access Checking concept is similar. In this concept, repositories represent the folders and models represent the files. That is, to be granted read access to a data model, you will not only need read access to the model it self but also to the repository containing it.

The Extensive Access Checking concept, however, is slightly more complex. The EDMuser and EDMgroup you are logged in with is granted access individually. Suppose your EDMuser has read access to an EDMmodel but your EDMgroup and Public does not have any access. Then you will not have read access if your EDMgroup has read access to the EDMrepository, but your EDMuser and Public does not have access.

If your log in EDMuser is owner or administrator of both the EDMrepository and EDMmodel, read access will be granted to the EDMmodel.

To modify the EDMmodel, you will need write access to both the EDMrepository and the EDMmodel.Suppose we have the somewhat unlikely protection patterns shown below.

In this situation, write access will granted with the Access Role OWNER_GROUP.

Access Roles

Access to protected objects is granted based on the logged in EDMuser and EDMgroup. When EDMsix checks access to a protected object, it will firstly determine will access role that applies to the EDMuser/EDMgroup. There are seven possible access roles.

Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'US:_icon_Important(30px)'.

Be careful when logged in as the EDMdatabase superuser. The superuser is granted full access to all protected objects, regardless of the protection settings.

Access Role	Description
OWNER_USER (Level 1 - 001b)	This is the highest possible access role to a protected object, (except for superuser). When creating a protected object, your EDMuser will automatically be the object owner. A protected object may only be owned by a single EDMuser. If you are the owner of the protected object, your access role will be OWNER_USER and you will be granted USER access to it, provided there are no restricting USER access settings on any of its parent protected objects.
ADMIN_USER (Level 2 - 010b)	When creating a protected object, your EDMuser will also automatically be added to a list of object administrator users. A protected object may have any number of object administrator users. If you are logged in as an object administrator user and you are not the object owner, your access role will be ADMIN_USER and you will be granted USER access to it, provided there are no restricting USER access settings on any of its parent protected objects.
OWNER_GROUP (Level 3 - 011b)	When creating a protected object, your EDMgroup will automatically be the object owner group. A protected object may only be owned by a single EDMgroup. If you are logged in with the owner group of the protected object, your access role will be OWNER_GROUP and you will be granted GROUP access to it, provided you have not already been granted a higher access role and there are no restricting GROUP_ACCESS settings on any of its parent protected objects.
ADMIN_GROUP (Level 4 - 100b)	When creating a protected object, your EDMgroup will also automatically be added to a list of object administrator groups. A protected object may have any number of object administrator groups. If you are logged in as an object administrator group, your access role will be ADMIN_GROUP and you will be granted GROUP access to it, provided you have not already been granted a higher access role and there are no restricting GROUP access settings on any of its parent protected objects.
ACCESS_FOR_USER (Level 5 - 101b)	If you have the OWNER_USER or ADMIN_USER access role to a protected object, you may grant special access to any number of entrusted EDMusers. If you are logged in as an entrusted EDMuser, your access role will be ACCESS_FOR_USER, and you will be granted the ENTRUSTED user access that has specially been set for you, provided you have not been granted a higher access role and there are no restricting USER access or ENTRUSTED user access settings on any of its parent protected objects.
ACCESS_FOR_GROUP (Level 6 - 110b)	If you have the OWNER_USER or ADMIN_USER access role to a protected object, you may grant special access to any number of entrusted EDMgroups. If you are logged in as an entrusted EDMgroup, your access role will be ACCESS_FOR_GROUP, and you will be granted the ENTRUSTED user that has specifically set for your EDMgroup, provided you have not been granted a higher access role and there are no restricting GROUP access or ENTRUSTED group access settings on any of its parent protected objects.
PUBLIC_ACCESS (Level 7 - 111b)	The lowest possible access role is PUBLIC_ACCESS. This is the access role you will be granted if you have not been granted any higher access role on a protected object and there are no restricting PUBLIC access settings on any of its parent protected objects.