nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Mandatory ACLs - Group intersections

saschavital

Hi,

I have a relatively simple requirement regarding how to secure my documents:

- Members of group A have READ permission

- Members of group B have READ permission

- Members of both group A and B have WRITE permission

Somehow, I would need to be able to AND the 2 groups in an Access Control Entry and assign the WRITE permission. My problem is how to manage this intersection of groups A and B in an ACL. With standard Content Server, you would have to create a manage an extra group reprensenting the intersection of A and B. I thought that TCS and mandatory ACLs would allow me to do this without any extra groups but that doesn't seem to be the case. Neither required groups nor access restriction are of any use, the was I see it. Since I have dozens of groups, and hence hundreds of intersections, it's not practical to manage group intersections on my own.

Any ideas?

Find more posts tagged with

Comments

Gane

hi Sascha Vital

For this case, you can have a TBO to perform this action and dynamically update the ACL.

Please share if any other better approach you implement for this requirement

bacham2

How is a TBO helping? The permissions on a document are something static.

Gane

TBO can help only when the ACL need to be atttached at the time of import, create,Save, checking etc. Where we can define our logic using DFC for forming ACL and attach to the document ( if we use seperate method and call from TBO will be best practice)

bacham2

That was not the question. The question was about how to compose the ACL.

I'm afraid that there are no alternatives other than using intersection groups.

saschavital

The problem is not so much about how to attach the ACL to an object, but how to design a set of groups and ACL-entries to allow a matrix access model. The ACLs in Documentum as I understand grant a user the highest privilege a group has on an object, where the user is member of. But I basically want to unlock this higher privilege only to a combination of groups, where as if someone is member of only one or two groups, he or she can maybe only read a document. Users either in group A or group B have read access, but users in both groups A AND B have delete access.

In fact we have about 5-10 dimensions with 10-100 values. The combination of these dimensions with the corresponding values is reflected as a group and users are synched to these groups automatically. As an example, one dimension is the country, another is the department and again another is the line-of-business, which could look as follows:

country:usa
country:uk
department:legal
department:hr
department:sales
lob:cars
lob:trucks
lob:trains

Now, how can I design the ACLs in a way, that for example users in {UK AND sales AND trains} have delete permission on uk-train-sales docs, but users only in {UK AND sales} or {usa AND sales AND train} have only read and users in {HR} have no access to those documents.

It is kind of difficult to explain in text, but I think it is a very common requirement of having such kind of "access windows" with higher privileges and I am looking for a smart design, which allows to build such combinations of groups and privileges in an automated and controlled way. I guess this is a requirement many companies have, if the want to share documents, but share them in a controlled way and share them for different combinations of groups with different levels of privileges?

Btw. we have TCS licensed and would be able to make use of MACLs, but sofar we have not found a smart design, which would support such combinations. The only technical way we found so far is the one described by bacham2 earlier in this post, by having intersection groups: in the example from before it would be a group called "uk:sales:train" ... but having 10 dimensions with 20 values at average we end-up in a worst case with 200! (factorial) groups (a number with 375 digits according to worlframalpha.com).

Do you have any ideas for a smart design?

DCTM_Guru

Which application are your users using to access the document? If webtop or taskspace, you can customize the delete action such that its only available based on your interaction. If you are using a different UI, you can give everyone just READ access and then create workflow that would call server method to delete that document. You can configure the server method to "Run As Server" to get around the READ permissions and apply the same group intersection logic to only execute if appropriate.

saschavital

An interesting approach!

We are moving from WebTop to pure DFC applications and moving the authorization to the application level is not what we want, because we can not avoid, that a user can not access the document through a different application (in extreme: iapi from the local workstation). Therefore we want to secure the documents on Documentum level, which makes it independent from the application accessing it.

However, the approach to give everyone read access and provide higher privileges through different means is a very interesting approach!

sivarry

Hi,

Another approach would be to use dynamic groups. Here is a rough design.

1) Create ACL(s) with 3 groups - Read Group (by default all your existing groups go here), Write Group and Delete Group

2) The Write and Delete groups may be dynamic groups

3) On Application login, resolve the user's access by checking the groups the user belongs to and arrive at the access level. Once the access level is calculated, issue a IDfSession.addDynamicGroup call to the relevant group. If the access level is read no call is issued as user has read access

Users when logged into other applications will only get read access but unfortunately it can be manipulated from IAPI . dm_add_dynamic_group and dm_remove_dynamic_group events can be audited to add more security.

Kindly refer to the Content Server Administration guide for more details on Dynamic groups

Regards,

Siva

saschavital

Hi,

great idea with the dynamic groups, which I will definitely follow-up! In fact it is not exactly solving the requirement, but it could get close enough to convince my "Access Management" architects.

What I will test is basically the following:

- Create MACLs with "accessor-groups", which represent the so called dimensions. Applications can choose if they want to create group-sets or they want to restrict access to a combination of groups. With this, users get the default privilege (e.g. read, annotate or version).

- This MACL in addition to the dm_world and dm_owner contains also a dynamic group, which is owned by and related to one business application only. And this is basically the piece, which we still have to test, who can activate an ownership of a dynamic group? Is it anyone? Or just the owner/administrator of the group? If only the owner/administrator of the group can activate this membership, then the application needs to do this only for every need of "higher" privileges (e.g. write, delete).

With this design we can allow members of single groups to read (or whatever is defined as the default privilege) the document through any application (e.g. iapi in a worst case), but the owning application can still decide about who has higher privileges.

Again, this is not quite what has been requested, because with this design the applications still have to "think" and authorize certain activities to a specific set of people. I was hoping we can do all this automatically with the built-in security features of Documentum ... will keep you informed and distribute more points once we have a solution.