Is this Security strategy possible?

[Kelly]

Hello,

I'm just about finished evaluating Everlive and Icenium, and I think it has everything I need. In fact, I think it's absolutely wonderful. There is one outstanding issue, though, that I need help understanding. I've tried adding Acls, but during the evaluation, I'm not allowed to use Item-level security. Before committing, I want to make absolutely certain I know this will work for me. Can you please tell me if the following scenario sounds plausible to you?

Consider two simple Content Types, Groups and Messages. Using the Master key I will add Groups, then add an Admin user to each Group. There could be hundreds of Groups/Admins.

As mobile users sign up, they will be made part of one Group at Sign up via Cloud Code.  At sign up the user provides the name of a Group, and beforeCreate looks up the Group's Id and stores it as part of the User record.

After eight sign ups, the data might look like this:

Groups     Users
------         -----
1        Admin1, 1, 5, 8
2        Admin2, 2, 3, 7
3        Admin3, 4, 6

Just to be clear, users Admin1, 1, 5 and 8 are part of Group 1. Admin2, 2, 3 and 7 are part of Group 2, etc. For each Group, only the corresponding Admin user will be able to add items for members of its group. Users other than the Admin cannot add items, so all items are owned by Admins. After a few are added, the Messages Content Type could look like this:

Id       Owner    UserId    Content
-----    -----    ------    -------
1        Admin1    5    Message 1
2        Admin2    2    Hi
3        Admin3    6    Hello
4        Admin1    8    Test 1 2 3

Here are my requirements:

Admin1 needs C+R+U+D access for all Messages for users 1, 5 and 8
Admin2 needs C+R+U+D access for all Messages for users 2, 3 and 7, etc.
Admin2 should not have any access to records for users 1, 5 and 8, and vice versa
No one can create a Group without the Master key
No one but an Admin can create a Message
User 1 needs R+D access for all Messages with user = 1
User 1 should have no access to Messages where UserId  <> 1
No one can have Master key access
No one can have any access to Groups

1) In general, does this look feasible? I don't care what combination of Roles, Content Type, or item-level permissions I need to use, as long as it can be accomplished.

2) What general permission scheme do I set for the Group and Messages content types? "Private" seems to be the only choice that would deny readers, but it allows writers. "Read-Only" prohibits writing, but would let anyone read. Shared and Public allow readers and/or writers. Ay carumba!

3) At the item level, for each Message, is it as simple as leaving the Admin as the item's owner, and adding an Acl that sets UsersCanRead and UsersCanDelete for the single user that is allowed to R+D the Message?

4) I had to open up the Groups Content Type for Anonymous access to get the beforeCreate cloud code to be able to look up the user's group. As noted, I don't want anyone but the cloud code to be able to read the Groups content type. How can I secure it from everyone, but keep the cloud code from getting the 403?

Thanks in advance!

Kelly

[Anton Dobrev]

Hello Kelly,

1. What you describe is certainly possible with Everlive. What we need to do is find out the best way to implement the security in your app so it is simple yet easily manageable.

2. All of the predefined security patterns allow some CRUD operation to anonymous users. To get the behavior you need you can use role-based security. It allows you to specify what CRUD operation is available for each role. If you deny all operations for all roles, CRUD actions will only be possible with masterkey access. Additionally, if you add new roles, they are automatically set to have no permissions, so you are safe on that front as well. You can read more about role-based security here.

3. You will find a proposition on the whole security system below.

We assume from the sample tables in your post that each group has a single administrator and each message is created for a single user.

If you want to register multiple admins to a group and to send messages to multiple users (always within this group) there is a different approach, which is also described below.

4. To prevent this error from the cloud code, you should use masterkey access from there. By default, when you use "Everlive.Sdk.$" requests are made using the authentication of the current request(anonymous in your case). You can easily make requests with masterkey if you use "Everlive.Sdk.withMasterKey()" instead of "Everlive.Sdk.$". You can read more about that here.

Here is the proposed security system for your app, based on what you described.

Roles:

Create role ‘Administrator’. By default there is the ‘Registered’ role that is assigned at the moment of registering of users if they are not assigned to a specific role.

In order to maintain the ‘multiple admins and message to many users in a group’ scenario create the following roles for each group - admin role and user role. For example, for Group1 you will have Group1Admin and Group1User, for Group2 - Group2Admin and Group2User, etc. You can then use those roles to define permissions for the messages. This way you can easily add administrators or users to a group, you just need to set the role of the user, without adjusting the granular permissions of the items in the group. Please note that this concept might not be optimal, if you have many groups - you will have to create many roles. Note however, that you can create roles from the SDK using masterkey access. In Everlive, every user has a single role. This means that with the above concept a user can only have access to a single group, either as an administrator or as normal user.

Groups:

Permissions:

This type should only be accessible with master key. This means that you should set its security to role-based and manually unselect all roles for all operations from Everlive’s portal (Types > ‘Groups’ > ‘Permissions’ tab). This will ensure that only requests with master key will be allowed.

Content type structure:

This type has an ‘AdminId’ field of type ‘Relation’ to ‘Users’.

Users:

Permissions: no permissions or access is granted to anyone, except: ‘Anonymous’ can ‘Create’ (to allow registering), ‘Owner’ can ‘Read’ (to be able to edit your profile).

Cloud code:

In the ‘beforeCreate’ event we would like to make the following checks:

• The provided by the user ‘groupId’ is checked and if such group exists the user is created.
•  For the created user the ACL ‘UsersCanRead’ is set to the ‘AdminId’ of this group. Thus the administrator will be able to only read the users of his group.

If you decide to maintain multiple admins and messages to many users: when creating users bound them to a certain group. You should set the role of newly created users to the role for that group. For example, if the user is admin of the group, his role should be in GroupXAdmin role. If he is a limited user, he should go to GroupXUser role.

Messages:

Permissions:

For this type the permissions are also role-based. The only checked option is for the ‘Administrator’ to ‘Create’ a message. This enables only the ‘Administrator’ to create messages. The ‘Owner’ of the message (which is the administrator) will have full access to the message.

Cloud code:

The administrator can create messages. When a message is created in the ‘beforeCreate’ event its ACL permissions for ‘UsersCanRead’ and ‘UsersCanDelete’ are allowed for the addressee’s ID.

With the other approach, role-based security should be applied to the Messages type and all roles should be excluded. Creation can only be done with master key. Every message is bound to certain group. When creating the message, its ACL should be set to allow READ from the GroupXUser role and to allow all operations to the GroupXAdmin role.

Please, let us know what you think on both approaches. In case of any other questions, please, do not hesitate to contact us. We would be happy to help.

Happy holidays!

Regards,
Anton Dobrev
Telerik