For my own understanding, I'm writing a Hierarchical Discretionary Access System. It is not DAC, it is more akin to Discretionary RBAC, but those details do not matter for the question at hand.
Each user has a certain Role; each Role has a certain set of permissions.
Each Role is organised in a hierarchical tree-like structure: the role named root has all permissions; child roles of root have a subset of the permission of their parent role.
Schematic views of the above:
Let's say that a user with the role named manager decides to delegate the permission named set_salary to a user with the role named programmer, who subsequently delegates this permission to the user with the role named intern.
Somebody decides to fire said user with the role named manager. As a result, the role named manager is revoked from said user. What is more, all permissions delegated by said user also need to be revoked.
So my question is:
Is there a data structure which facilitates easy identification of:
the chain of permissions delegated by a certain subject within a hierarchical tree structure;
whether or not a certain permission has been delegated to a certain subject?
How about an adjacency list ?
Or in other words, 'a list of linked lists', similar to how we use it in representing graphs.
Each user can be associated with a delegation linked list.
A node of the delegation linked list can be of the form <permissionId, userId>, denoting that the owner of the linked list has delegated the permission permissionId to the user userId. Then we can go through the linked list of the user userId and repeat the same process recursively until we find a user whose delegation linked list is empty.
This algorithm is basically the same as Depth-first search.
This model can't support delegation of permission per a user like you described for manager -> programmer -> intern situation. Permissions are set for a role and setting new permission for a role effects all users that has that role.
To support permission delegation per a user, new relation is needed that describes delegation. Data needed to describe it is: which user gave permission, which user received permission and permission that is delegated. Like, relation delegatedPermission with columns:
giveUserId
receiveUserId
permissionId
Related
In CloudCode, is there any utility function which I can determine that the current user belongs to a certain role?
Assume the following role hierarchy Admin->Manager->User
If I added user1 to the Admin role, this means if in cloud code if I query all the roles this user belongs to, then I will get immediate list of roles not hierarchy. I am wondering if there is a utility function that helps with this issue?
In Microsoft Dynamics CRM 365 the security roles have an "Append" and "Append To" rights. What does "Append" and "Append To" mean and what is the difference between them?
I googled for the answer, but cannot find a definitive one.
Append and Append To are two privileges that most user are not very clear about regarding their functionality. In this article we try to explain the difference between “Append” and “Append To” Privileges and how it affects the user access.
Append and Append To basically deal with the entities that are parties to a 1:N relationship or N:1 relationship.
Append: When an entity has the lookup of another entity on its form. It is important that the user has the “Append” privilege on this entity so that it can set the values for the lookups on this entity. For eg: Contact has the lookup of Account on its form so here the user needs to have the “Append” privilege to be able to set the parent account.
Append To: When an entity is available as a lookup on another entity form. It is important that the user has the “Append to” privilege on the entity that is referred to in the lookup so that it can set the values for the lookups of this entity on any other form. For eg: Account has the lookup of primary contact. So here the user needs to have the “Append To” privilege to be able to set the Primary Contact for the Account.
Lets us take an example of Contact entity.
We have modified the Order Role and removed the “append” privilege to the Contact entity.
When a user with this role logs in, they would find the Parent Account lookup disabled.
This is because the user does not have the “Append” privilege to the contact entity. So all the lookups on the contact form are Disabled.
Now we have modified the Order Role and provided the “Append” privilege for the contact entity and removed the “Append To” privilege from the contact entity.
The Primary Contact on Account is disabled.
It means the lookup of contact entity will be disabled on all the entities if the “append to” privilege to contact is removed.
Reference for the blog: https://community.dynamics.com/crm/b/crminogic/archive/2010/05/03/append-v-47-s-append-to
You probably won't find anything because there is no concept called "Assign" and "Assign To" rights.
We have "Assign", "Append" and "Append To" privileges.
Assignment is nothing but changing the owner lookup value of the entity record from user A (or Team X) to user B (or Team Y).
Excerpt of better definition for Append and AppendTo:
One way of thinking conceptually about Append and Append To is to think of ‘Append Me‘ and ‘Append To Me‘.
In order to successfully append record A to record B, the security privileges must be set to allow both sides of the agreement. Consider the following metaphor, Append ‘knocks on the door’ of another entity and Append To is needed to ‘open the door’ to that entity. For example, if you want to qualify an Account and begin working the opportunity as set in your business process flow, you must have to rights to append the Account (record A) and the rights to append to the opportunity (record B).
Read more
Using the Google Classroom API method userProfile, I can get various information about a user, including their name and email address, but not whether they are a student or teacher. How can I determine whether a user is a student or teacher?
Classroom does have the concept of teachers and students, however the distinction between teachers and students is only meaningful relative to a particular course (it’s possible for a user to be a “teacher” of one course and a “student” of another) and so you might not be able to use these categories to apply access controls in the way you were expecting.
For example, if alice#school.edu is a member of a particular course’s courses.teachers collection, and bob#school.edu is a member of courses.students, then you can use this information to decide that bob#school.edu should not see certain content created by alice#school.edu. (For example, you might not want to show Bob the answers to a quiz that Alice has created on your website, just the questions.)
However, because by default all users can create courses, you probably do not want to show alice#school.edu sensitive information created by teachers of other courses, information intended for teachers that you provide (for example, if you are a textbook publisher), or giving her domain-wide admin features.
If you need to distinguish between “real-world” teachers and students, we recommend that you do this via a mechanism entirely separate from Classroom, such as checking that the user’s email address appears in:
a separately-maintained list of teachers (e.g. CSV uploaded by admin)
the classroom_teachers group – domain administrators can choose to verify teachers to allow them to create new classes (use the Directory API to list a user’s groups)
Classroom api dosent provide global role for a teacher or a student its vary from course to course so you can just call student/teacher api
after that you will get json output and you find a special permission for teacher "Create Course" it will help you to recognized that the person is teacher.
"permissions": [
{
"permission": "CREATE_COURSE"
}
]
in case of student this array will be null.
This question is really made of two parts.
Using Parse, I'd like to have the following [simplified] scheme, where I have Users who are part of secret groups, and there are discussion that can appear across a few groups at one. That is Users who are part of Group A also are added to the GroupA role, and have access to discussions in Group A.
My trouble is, when I create a new discussion and tell it the groups it should appear in, how do I query for the roles and add them to the Discussion as well? I'm really fuzzy on this roles/ACLs business, even after reading extensively.
User(firstname, lastname)
Group(members, secrets)
Discussion (groups, note, comments)
Create a Role when you create a Group. Assign a pointer from the Group to the Role. Set the ACL for the Group to the Role (for write, it can be public read or whatever you want). When you add users to the Group, add them to the Role so they have access through the ACL.
For your Discussion you need to add all of the appropriate Roles from all of the Groups to the ACL list so that all of the users in all of those Roles have access.
Imagine a website that agregates online ordering for many restaurants and is built using parse.com.
In parse.com there is a class called Order where all of the orders are stored.
Each order belongs to one, and only one, restaurant.
When querying the Order class, each restaurant can only read (and write) its own orders. A restaurant should not see (and write) orders for other restaurants.
To solve this, I've tried using one role per restaurant and add the restaurant-role to the each restaurants order's ACLs. So I've created one role for each of the Restaurants using the following naming taxonomy: Restaurant-[restaurantObjectId].
I have taken care that user's belong to their respective restaurant-role.
I've also fiddle with Class Level Permissions (CLPs) without results: either total access or total lack of access, none of access limited to restaurant data.
Any clues?
It seems that one has to have make the Find operation available to the Public. Otherwise it gives the not authorized error.