I have a short question - is there a way to DENY already given permission ?
I have a 2 cases where i'll want to use that feature:
1, i have a user that is in particular group, which has some regular permissions, but i want to (temporary) remove some permissions from that group - like "add" but keep rest of them untouched (edit, delete,.. )
2, same group as above, has permissions to my 4 custom apps, but i want to "ban" user from one of them, and leave those 3 untouched
So no i think that simple denying feature could be a proper way to do this and keep it easy to maintain in future (no need to have multiple groups etc)
Or maybe someone can guide me to a different and smarter way to solve my problem?
Thanks in advance for any reply.
Related
I a newbie to AWS. My requirement is to add field-level, document-level, and collection-level permissions for reads and writes for AWS DocumentDB. One collection should accessible only from one microservice and the document should be modified only by the owner of the document(i,e user document can be modified only by that user)
I have done enough research and found, adding a restriction for accessing a DB can be done using Role-Based-Access-Control if we want to allow only for one tenant, but didn't get a clear idea of my problem statement i.e managing collection-level, document-level, and field-level permissions
Is there any other way to achieve this..?
Any help will be appreciated
I just try with AWS cognito for authentication my web application.
I am using Warrant library https://github.com/capless/warrant
I have many users which belong to my group (Ex: G1, G2, G3)
However, I cannot find the way to get list of users for specific group.
Can anyone tell me how to get list users in specific group?
Thank in advance.
I've just passed by the same situation as you, because I'm using warrant to. The problem is that warrant is an high level library, so it doesn't have capacity to manipulate all features that cognito can provide.
So, if you can try to solve this problem without using warrant, my solution is to use boto3 identity provider api, an low level feature that works with various usefull features of cognito.
Check these low level functions in AWS API documentation
So, using these functionalities, I made the code bellow to list all users at some group:
import boto3
cognito_cl = boto3.client('cognito-idp')
res = cognito_cl.list_users_in_group(
UserPoolId=<some_pool_id>,
GroupName=<some_group_name>
)
group_users = res.get('Users', 'empty')
Then, if you access group_users variable, you can see the list of all users in this group, just like all of their attributes.
Hope that I have helped you even after so long.
I am trying to check if a user has a permission, which I have defined in the class Meta of the model, with a specific codename. At the moment I have:
if request.user.has_perm('app_label.code_name'):
do something
What I am trying to avoid is using the app_label, however using has_perm('code_name') does not seem to work.
The way this function works is that you need to pass the app_label, so not much you can do there.
One workaround can be to write your own wrapper function, something like:
def _has_perm(user, code_name, app_label="app_label"):
return user.has_perm(app_label + "." + code_name)
The reason you need to provide the app label is that permissions are application specific. That means if you have two apps, app_a and app_b, both with a model named Farm, they could both have a permission called can_create_new_chickens. It is very important to understand that there are two separate permissions here:
app_a.farm.can_create_new_chickens
app_b.farm.can_create_new_chickens
These are independent permissions, and a user can have neither, both or one or the other. This means it would be insecure to validate permissions without referring to the application name. Permissions given to a user in one application could affect their permissions in another application.
Back to your question, the answer is no, you cannot check permissions without the application name for the reasons given above.
I'm using FreeIPA as an LDAP-backend for my flask-app. So far I've used flask-simpleldap with OpenLDAP to get the group membership of a user, which works fine with the following options:
LDAP_BASE_DN="dc=myrealm,dc=com"
LDAP_REALM_NAME="MyFunRealm"
LDAP_OBJECTS_DN="dn"
LDAP_USER_OBJECT_FILTER="(&(objectclass=inetorgperson)(uid=%s))"
LDAP_GROUP_MEMBERS_FIELD="member"
LDAP_GROUP_OBJECT_FILTER="(&(objectclass=groupofnames)(member=%s))"
LDAP_GROUP_MEMBER_FILTER="member=%s"
LDAP_GROUP_MEMBER_FILTER_FIELD="cn"
I want to change the LDAP structure of my users to place groups inside groups, but the above settings only gives the users' "first level" group. (Sorry I'm unfamiliar with LDAP and it's terminology).
How can I change the query/filter to get a list of all groups the user is a member of through group-in-group membership?
I don't think it is possible considering your setup (ie flask + openldap)
OpenLDAP does not (from my knowledge) have built in mechanism to perform filter on nested groups.
And flask does the request for you, so you can't implement the recursive search easily.
In other directory (AD for example) you can specify the extensible matching rule for filtering nested groups, something along this line :
(&(objectclass=groupofnames)(member:1.2.840.113556.1.4.1941:=%s))
But this specific extensible matching rule does not exist in OpenLDAP
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.