Forums (Obsolete)

Member

lawrence.dine-moov2 - 5/21/2012 10:59:02 AM

Document Tree Permissions - private areas and different levels of member

Hi,

I'm trying to create a site with a complicated set of access rules for various memberships and roles. Basically I need to be able to deny access to any given part of the document tree for all users except those of a certain role. My problem is that if I try to set the roles as: 'deny read Everyone' and 'allow read MyRole' users with MyRole still can't see the content.

Does this mean that any deny at all will stop a user from having that permission? Even if they have another (more specific) role that says allow?

If so, is there another way that I can deny read to sections of the document tree form members who aren't of a specific membership?

Thanks,
Lawrence


Kentico Legend	Brenden Kehren - 5/21/2012 11:15:27 AM RE:Document Tree Permissions - private areas and different levels of member Technically users in "MyRole" are also part of the "Everyone" role which is why you are getting the unexpected results. So your solution is to specify the other roles and denying access to them and allowing access to "MyRole".

Kentico Support

kentico_radekm2 - 5/22/2012 1:38:09 AM

RE:Document Tree Permissions - private areas and different levels of member

Hello.

FroggEye is right. Deny permission is always stronger than allow. So, if some user shares two roles (and every user is also member of Everyone role) and any of these roles has Deny permission, the result is always deny then. So, you need to deny given permission to all roles given user does not belong to.

Best Regards,
Radek Macalik

Member

lawrence.dine-moov2 - 5/22/2012 3:18:52 AM

RE:Document Tree Permissions - private areas and different levels of member

This seems strange to me, let me give a more in depth example to confirm I understand this correctly:

I have 3 memberships memA, memB and memC, I have a role for each membership RoleA, RoleB, RoleC.
Finally I have 3 sub sections of my document tree; A, B and C.

I want each membership to only have access to its own section and users with no membership to have no access. Am I correct in thinking that I would have to do this:
A
RoleA allow read
RoleB deny read
RoleC deny read
(role that I've added all users who are not part of my membership) deny read

And so on for the other sections.

Further to this, I might have another section called A-Gold which is only available to a sub-set of my A membership who have gold access. Am I right in thinking that I can't do this? My RoleA will overwrite any allow access I give to this subset, I'll have to create a seperate membership with a role with the duplicate permissions of RoleA just so I can allow this sub-section?

Kentico Support

kentico_radekm2 - 5/25/2012 7:32:22 AM

RE:Document Tree Permissions - private areas and different levels of member

Hello.

If I am not wrong, you can set permission for users or roles only, not for memberships.

Memberships are mainly intended to be used in combination with e commerce for live site users and customers, or for other specific purposes where an additional security layer that groups together multiple roles is useful.

If you need to define authorization options for different types of users, such as content editors or administrators for specific modules, it is recommended to do so directly using standard roles.

Particular solution depends on complex security settings you have. You can set permissions for module, document type or document level. Result (final permission) depends on all three settings, as there is some hierarchy. For example, if you allowed permission (e.g. Read) for some particular document type (e.g. cms.news) and role (e.g. Role A), given role can read all documents of the given document type, if you don’t deny it for it on document-level. However, if some role doesn’t have Read permission nor for module Content or the document type, it needs Read: Allow on the document level.

You can see more info about all three layers and some examples at http://devnet.kentico.com/docs/devguide/permissions_for_modules_and_documents.htm.

Best Regards,
Radek Macalik

Member

lawrence.dine-moov2 - 5/25/2012 8:08:51 AM

RE:Document Tree Permissions - private areas and different levels of member

Yes you are correct you can't directly set permissions on memberships but you can give memberships roles which is what I was referring to.

Our site needs to have its normal users in groups and each group will have access to certain areas of the site, sometimes there will be sub-groups that will have access to the same as their parent group and possibly more too. I chose memberships because you can actually apply Roles to those 'Groups' in Kentico have Roles but they're not the same as the security Roles that you use to set permissions.

Deny taking priority seems an odd choice to me as it limits your ability to easily give a certain group access to one thing. Can you imagine if file system permissions worked like this? That would be impossible to manage.

Perhaps a good future addition to Kentico would be a way to invert roles; e.g.: Everyone except people with this role get deny read.

I managed to almost get the desired functionality in the end with the only issue being that I need to make a new role for the group every time I want to add a sub-permission to a group. Meaning I need to make A-Gold, B-Gold, C-Gold, even if the roles essentially do the same thing.

I wouldn't say giving certain groups of users private access to certain areas of cms content is a particularly complex security requirement.

Kentico Support

kentico_radekm2 - 5/30/2012 8:34:12 AM

RE:Document Tree Permissions - private areas and different levels of member

Hello.

I understand your opinion and I also agree with you about Deny priority rule. I can imagine it will be easier in some scenarios, if Allow permission would be the main, so you don’t need to deny all other roles or users.

We value every feedback and good ideas, so I would recommend you to submit this as a new feature request at http://www.kentico.com/Support/Suggest-feature. We will consider it for some future release. Thank you.

Best Regards,
Radek Macalik