Using tastypie, how do I only authorize authors of objects the ability to edit/delete objects they have created? For example, if user 1 created an object A, how can I make it so user 2 cannot edit or delete object A but user 1 can edit or delete object A?
Check this cook-book entry:
http://django-tastypie.readthedocs.org/en/latest/cookbook.html#creating-per-user-resources
If that doesn't fit you well, there is an WIP on per-object permissions in the perms branch of tastypie repo. You might want to check that out but beware that it's not ready yet.
Related
I have an AWS Amplify application that has a structure with multi-organizations:
Organization A -> Content of Organization A
Organization B -> Content of Organization B
Let's say we have the user Alice, Alice belongs to both organizations, however, she has different roles in each one, on organization A Alice is an administrator and has more privileges (i.e: can delete content or modify other's content), while on Organization B she is a regular user.
For this reason I cannot simply set regular groups on Amplify (Cognito), because some users, like Alice, can belong to different groups on different organizations.
One solution that I thought was having a group for each combination of organization and role.
i.e: OrganizationA__ADMIN, OrganizationB__USER, etc
So I could restrict the access on the schema using a group auth directive on the Content model:
{allow: group, groupsField: "group", operations: [update]},
The content would have a group field with a value: OrganizationA__ADMIN
Then I could add the user to the group using the Admin Queries API
However, it doesn't seem to be possible to add a user to a group dynamically, I'd have to manually create each group every time a new organization is created, which pretty much kills my idea.
Any other idea on how I can achieve the result I'm aiming for?
I know that I can add the restriction on code, but this is less safe, and I'd rather to have this constraint on the database layer.
Look into generating additional claims in you pre-token-generation handler
Basically you can create an attribute that includes organization role mapping
e.g.
{
// ...
"custom:orgmapping": "OrgA:User,OrgB:Admin"
}
then transform them in your pre-token-generation handler into "pseudo" groups that don't actually exist in the pool.
A user story has an Owner and Assignments. Trying to figure out the best use of Owners, Assignments and Roles.
When you create an entity, your user becomes listed as Owner. Any item can have only one owner at a time.
An owner can always edit and delete his items, even if his role doesn't have edit or delete permissions for this type of items. This allows every person to edit or delete items they created by mistake.
Not everybody can change owner for an item; there is a special role permission 'can change owner' in the roles settings. If you don't have such permission (even with Add/Edit/Delete permissions) you still won't be able to change the ownership.
Each entity can have unlimited amount of people assigned to it. Usually you assign a person to an entity, if this person is going to work on it.
Any user can always change the state of the items he's assigned to, even if his role doesn't have edit permissions for this type of items. This allows every person to mark their share of work as completed.
Role indicates what kind of work this person will perform (development \ analysis \ testing \ etc.). A set of available roles can be customized as described at https://guide.targetprocess.com/settings/how-to-customize-assignments-area.html
Role also affect what you'll see in your ToDo list: https://guide.targetprocess.com/filters/filters-for-personal-todo-list.html
I am using IS WSO2 for authorization with XACML. I am am able to achieve authorization for static resource. But I am not sure with the design when it comes to granularization.
Example : if I have method like getCarDetails(Object User) where I should get only those cars which are assigned to this particular user, then how to deal this with XACMl?
Wso2 provides support for PIP where we can use custom classes which can fetch data from database. But I am not sure if we should either make copy of original database at PDP side or give the original database to PIP to get updated with live data.
Because Cars would be dynamic for the application eg. currently 10 cars assigned to user Alice. suddenly supervisor add 20 more car in his list which will be in application level database. Then how these other 20 cars will be automatically assigned in policy at PDP level until it also have this latest information.
I may making some mistake in understanding. But I am not sure how to deal with this as in whole application we can have lots of this kind of complex scenario where some times we will get data for one user from more than 4 or 5 tables then how to handle that scenario?
Your question is a great and the answer will highlight the key benefits of XACML and externalized authorization as a whole.
In XACML, you define generic, global rules, about what is allowed and what isn't using what I would call high-level attributes e.g. attributes of the vehicle (in your case) or the user (role, department, ...)
For instance a simple rule could be (using the ALFA syntax):
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowSameRegion{
permit
condition user.region==car.region
}
}
Both the user's region and the car's region are maintained inside the application's database. The values are read using a PIP or Policy Information Point (details here).
In your example, you talk about direct assignment, i.e. a user has been directly assigned to a vehicle. In that case, the rule would become:
policy viewCars{
target clause actionId=="view" and resourceType=="car"
apply firstApplicable
rule allowAssignedVehicle{
permit
condition user.employeeId==car.assignedUser
}
}
This means that the assigned user information must be kept somewhere, in the application database, a CSV file, a web service, or another source of information. It means that from a management perspective, an administrator would add / remove vehicles from a user's assigned list (or perhaps the other way around: add / remove assigned users from a vehicle's assigned user list).
The XACML rule itself will not change. If the supervisor adds 20 more cars to the employee's list (maintained in the application-level database), then the PDP will be able to use that information via the PIP and access will be granted or denied accordingly.
The key benefit of XACML is that you could add a second rule that would state a supervisor can see the cars he/she is assigned to (the normal rule) as well as the cars assigned to his/her subordinates (a new proxy-delegate rule).
This diagram, taken from the Axiomatics blog, summarizes the XACML flow:
HTH, let me know if you have further questions. You can download ALFA here and you can watch tutorials here.
I would like to automatically create some objects instance when a new user is created. I think using signals would be the best strategy but it seems there is no signal attached to user creation.
I am also using django-registration, but I would prefer using signals on user creation rather than on user registration.
What is the best approach for such purpose?
I'm designing a REST service which organizes groups and users.
For example:
GET /groups - gets all the groups
GET /groups/1 - gets a specific group
GET /groups/1/users - gets the users in the group
GET /users/1 - the actual user, which may be in multiple groups
POST /groups/1/users - with the post parameters of user_id=1 to add a user to a group
What would be the appropriate way to handle this?
DELETE /groups/1/users/1 seems to be a valid way to do it but then the GET to the same url would return the user record which is a duplicate of the resource /user/1?
or should it be DELETE /groups/1/users?user_id=1?
Wondering which is the most RESTful way to do this.
I think that a good design would make explicit the membership of a user within a particular group - as a separate resource. So, there are groups, users, and the membership of a user within a group.
Therefore, GET /groups/1/users would return a list of membership resource identifiers: /groups/1/users/{member_id} on which you could do a DELETE. Each of these "memberships" is of course associated with a particular user, so you would have to somehow know which member_id is associated with which user_id. The easiest way to do this is to make member_id have the same semantics as user_id, as you suggest in the question (so /groups/1/users/1 means "user 1's membership in group 1"). Following that, if you do a GET on /groups/1/users/{member_id} you could just redirect to /users/{user_id}. Or in a more complex example, this resource would no redirect to a user but link to it and also include some other information, for example the date when the user joined the group, her status in the group, etc.
The other option I can think of would utilize the PATCH method to modify the collection resources (/groups/1/users): see https://www.rfc-editor.org/rfc/rfc5023. But using a DELETE seems more natural.