Access Control Lists (ACL) in the DTR 

An access control list (ACL) defines the privileges principals (these can be an individual user or a user group) have for a particular resource. Technically speaking, an ACL consists of access control entities or ACEs. It also assigns one or more privileges to a principal.

The figure below shows the class diagram of the access list:

 

Class diagram of the access control list (ACL)

The component model allows you to specify for an individual grant in an ACL if "entity forwarding" is allowed. This flag determines if a using Development Component (DC) may have entity references to the affected public part(s) of the used DC. This allows two ways of granting access to using components:

●      The using component may use the DC and forward the public part content as part of its public part. This includes the option to publish this content with a less restrictive ACL. (Forwarding Allowed=true)

Granting access to a DC with forwarding allowed means you highly trust the owner of that DC.

●      The using component may use the DC or public part (to compile against it, to pack it into a deployable result). However, it is not allowed to expose the content of the used public parts in its own public parts. (Forwarding Allowed=false). In this case, the using DC has no chance to offer the used API with a less restrictive ACL.

If you want to prevent someone from forwarding your API (maybe with a less restrictive ACL), then set the Forwarding Allowed to false.

Preventing forwarding may be a good idea for anonymous grants (dcname="*" or scname="*" ) because in that case you normally do not know the users and whether you should "trust" them.

Rules

It is not necessary to define ACLs for all resources. On the other hand, it is possible to define different ACEs for one resource that exclude one another. To solve these conflicts, the permissions are interpreted according to a set of rules that independently apply to all privileges.

The resource path is used to determine the permissions. The permissions do not need to be defined for all resources: a resource of a child hierarchy level inherits all permissions granted to a parent folder, unless permissions are granted to the child resource directly.

Rule 1 – “final“ Before All “Children“

A final ACL annuls all other ACLs that have been defined for the child resource.

The “final“ attribute enables a system administrator to temporarily set areas of the Design Time Repository (DTR) into a “read-only“ state without having to delete all existing permissions.

The following permissions apply:

Resource	Inheritance	Principal	Privileges
/		administrators	grant adminX
/projects		developers	grant read
/projects/java/dev		developers	grant write

Assume that you want to execute an administrative task that requires all members of the developers group not to check in changes to the DTR. To do this, you must deny a write privilege to ”/“ using final. In addition, the access control list must be declared as final.

Resource	Inheritance	Principal	Privileges
/		developers	deny write

Rule 2 – “ignore inheritance“

This rule allows you to use the attribute ”ignore inheritance” to interrupt the inheritance hierarchy. A resource for which an ACL labeled as “ignore inheritance“ is defined does not inherit any authorizations from superior folders.

There are two project groups DevelopersA and DevelopersB. All project members of these two groups are also a member of the Developers group. In the directory structure /projects/A/java/dev/project-internal, the following permissions are granted:

Resource	Inheritance	Principal	Privileges
/projects		Developers	grant read
/projects/B/java/dev		DevelopersB	grant write
/projects/A/java/dev		DevelopersA	grant write
/projects/A/java/dev/project-internal	ignore inheritance	DevelopersA	grant read grant write

■       All members of group Developers can read everything below the /projects directory, except directory /projects/A/java/dev/project-internal: Only members of group DevelopersA have read access to this directory.

■       All members of group DevelopersA have read and write access to all resources below the /projects/A/java/dev directory.

■       All members of group DevelopersB have read and write access to all resources below the /projects/B/java/dev directory.

Rule 1 has priority over rule 2. This means that if, for a parent resource, a final ACL has been defined, all ACLs to child resources are ignored, even if they have been defined with ignore inheritance.

Rule 3 – “Child” Before “Parent“

This rule allows you to refine permissions for child resources.

To the directory structure /projects/java/dev/.../secret/.../confidential, you want to grant the following permissions:

Resource	Principal	Privileges
/projects	Developers	grant read
/projects/java/dev	Developers	grant write
/projects/java/dev/.../secret	Developers	deny read deny write
/projects/java/dev/.../secret/.../confidential	User07	grant read grant write

■       All members of group Developers can read everything below the /projects directory, except the directory secret.

■       All members of group Developers have write access to all resources below the dev directory, except to the subtree below secret.

■       Only user User07 can access the subtree below confidential (read and write). But not even this user can access the resources between secret and confidential if he or she is a member of group Developers.

Rule 4 – ”user” before ”group“

This rule defines the priority for contradicting ACEs defined for the same resource (because this rule is defined after rule 3, it can affect only the same resource). This rule gives the user entry priority over the group entry.

 

■       User X belongs to group A.

■       Group A has the deny write permission for resource /ws/wsdir/myws/com/tssap.

■       User X has grant write access for the same resource.

In this case, user X is allowed to write to the resource, even though members of group A are not allowed to.

Rule 5 – ”deny” before ”grant“

If for a privilege there is a grant as well as a deny permission, then deny takes priority. Because this rule is applied after rule 4, it can affect only colliding permissions for the same user or for user groups with a common member.

■       User X belongs to group A and to group B.

■       Group A has the grant write permission for resource /ws/wsdir/myws/.

■       Group B has the deny write permission for the same resource.

In this case, user X is not allowed to write to the resource. However, rule 3 still applies (user before group).