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; } } }

Interesting Security Requirement -- Any takes on it?

Soohail_Aboobaker

Hi,

We came across an interesting security setup requirement that is not achievable through WEM standard security mechanism. Please let me know if I am mistaken on this.

The requirement is to setup a WCM user with different capabilities for content in different folders. For example, the user can have author role and editor role but when (s)he accesses content in folder-a, (s)he should have capabilities of author but in folder-b, (s)he should be editor role.

As far as my understanding is concerned, this request may be a business use case but it goes against the basic security design in Open Text WEM i.e. roles provide capabilities to "perform" actions in the system while user groups provide permissions to perform those actions in specific locations / folders. If a user has a capability through a role, we can not restrict that capability on one folder and not on other.

Have you come across this requirement before and how did you address it?

Thanks.

Sohail

Find more posts tagged with

Comments

Evan_Bench

actually it is part of WEM security called "ACL" (Access Control List). Here's how to do it:

1. Using AppConsole, select the folder

2. Click on Security

3. Click on Advanced

4. Add a role, group, or user

5. Click on "Capabilities"

6. Select to "Deny" or "Grant" a specific capability for that folder only.

This can also be done for practically anything else (channels, workflows, object types, sites).

Easy! But, don't use ACL too often as it is a bit difficult to determine "Net" security. Best practice is to use sparingly and only with Groups (but it does work with specific users)

eLink User

Thanks Evan
We are aware of ACL but as you mentioned it is better to use ACL for edge cases and not as part if main security architecture.
Since this case is presented as normal business case, ACL might not be the answer for it. I do not see any other way of implementing this requirement.

Sohail

On Jan 5, 2013 1:58 AM, "eLink Entry: Discussion Group - Web Experience Management" <v7webcontentmanagement@elinkkc.opentext.com> wrote:

Interesting Security Requirement -- Any takes on it? Posted byebench@opentext.com (Bench, Evan)On 01-05-2013 01:52

actually it is part of WEM security called "ACL" (Access Control List). Here's how to do it: 1. Using AppConsole, select the folder 2. Click on Security 3. Click on Advanced 4. Add a role, group, or user 5. Click on "Capabilities" 6. Select to "Deny" or "Grant" a specific capability for that folder only. This can also be done for practically anything else (channels, workflows, object types, sites). Easy! But, don't use ACL too often as it is a bit difficult to determine "Net" security. Best practice is to use sparingly and only with Groups (but it does work with specific users)
[To post a comment, use the normal reply function]
Topic: Interesting Security Requirement -- Any takes on it?
Forum: Discussion Group - Web Experience Management
Content Server: Knowledge Center

Evan_Bench

HIi VignAdvisor,

I respectfully disagree. ACL is part of the standard security architecture and it does meet the requirements that you indicated. The best practice however is to assign the appropriate capabilities to the roles, then map that role to an ldap group. That group is then given authorization to any system object (normally channels, folders but also any object is possible).

Then if you need to allow (or deny) any specific capability for any specific object you can use ACL. Thus if you have a well-planned security model in place (using roles and permissions) then you don't need to use ACL that often. That's all I'm sayin...

Kind regards,

Evan

eLink User

Thanks,

We are both saying the same thing in different words.

Sohail

On Sun, Jan 6, 2013 at 6:57 AM, eLink Entry: Discussion Group - Web Experience Management <v7webcontentmanagement@elinkkc.opentext.com> wrote:

Re Interesting Security Requirement -- Any takes on it? Posted byebench@opentext.com (Bench, Evan)On 01-06-2013 06:56

HIi VignAdvisor, I respectfully disagree. ACL is part of the standard security architecture and it does meet the requirements that you indicated. The best practice however is to assign the appropriate capabilities to the roles, then map that role to an ldap group. That group is then given authorization to any system object (normally channels, folders but also any object is possible). Then if you need to allow (or deny) any specific capability for any specific object you can use ACL. Thus if you have a well-planned security model in place (using roles and permissions) then you don't need to use ACL that often. That's all I'm sayin... Kind regards, Evan
[To post a comment, use the normal reply function]
Topic: Interesting Security Requirement -- Any takes on it?
Forum: Discussion Group - Web Experience Management
Content Server: Knowledge Center

--
Regards,
Sohail Aboobaker.
Accumulate Consulting Inc.
www.letsaccumulate.com.
Ph: 416 907 9050

Evan_Bench

Hi Sohail, great to meet you in person last week at CoT. After seeing the requirements "live" I do see the restriction you refer to. The "problem" is the shared capability (VCM:MODIFY) that is needed for both editing content and associating content to a channel.

What I think would be a good solution is to customize the button group to look at a 'fake' capability (add a new row to the capabilities table called something appropriate "realeditor" for example). Then filter that button based on this new capability. So, only those who are so-called real editors can edit while others can associate to their channel (but not edit).

There are some examples of this on the EIM and COE communities (Sreekanth did these I think). I left details on this with James and Victor.

Again great to meet you in person and let me know if I can help out in some way with this project,

Evan