I am new to the framework cakephp and I am using the Authentication component as well as the ACL. I have followed this tutorial: http://book.cakephp.org/2.0/en/tutorials-and-examples/simple-acl-controlled-application/simple-acl-controlled-application.html to get me started.
How do I give a not logged in User a role (group) ACL such as 'Guest'?
Should I even consider giving a not logged in user such a role (group) ACL? I mean would it bring any disadvantages?
Usually you would not give a role to a user that is not logged in, because the user would not have a record in the user table therefore the User could not belongTo a Role. If you wanted to do alot of special programming I guess you could do it, but I don't see a point.
Most people just allow non-authenticated and authenticated users access to various parts of there app with the $this->Auth->allow() parameter in the controller. Then they section off other parts of the application to allow certain authenticated Users belonging to certain Roles to access with ACL.
http://book.cakephp.org/2.0/en/core-libraries/components/authentication.html#making-actions-public
Related
For two of my snowflake user accounts, an icon is showing up on the right that has a popup when I hover over it:
Why is this link showing up for two of my users?
Obviously I'm now confused about what these two "users" are and how they were created:
Are these users really service accounts?
If so, what is a snowflake service account and how does that differ from a user?
How do I designate some user accounts as service accounts and what are the pros/cons of doing so?
I've tried clicking the button and it just takes me to the user account details page and I don't see any "create user" type of language on the account details page.
I've tried to find anything in Snowflake's documentation that indicates a difference between service accounts and user accounts but I only find blog posts about how you need to treat your service accouns with care (and implement password rotation policies, etc).
I can't find anything definitive (yet) about designating users as "service acounts". (The closest thing is this stackoverflow about how service accounts are the same as normal user accounts.
Obviously there is something special about these two user accounts, though, since the snowflake UI is indicating these two users are actually service accounts.
The icon appears when a comment is set for the user. This comment can be set by yourself for a user to determine what is the purpose of it.
You may un/set it using the statements:
alter user user1 set comment='Create New User for Service Account';
alter user user1 unset comment;
More details: https://docs.snowflake.com/en/sql-reference/sql/alter-user.html#alter-user
I have a Microsoft Teams group tab and I'd like to implement a permission system in which users can do different things in the tab depending on their role in the team (or channel). The context I get from the Teams JavaScript API cannot be trusted, so I have to check group/team/channel role through the MS Graph API.
The only way I've found to check whether a user is an owner or only a member of a team is to call /teams/{groupId}/channels/{channelId}/members. In the response I can see which roles users have and I so I can find out if the current user has owner privileges.
The problem is that this endpoint requires admin consent (I guess because it displays data of other users). I'd like to avoid having to ask for admin consent, however. Is there another way of finding out about the role of a user in a team without admin consent? (As private channels behave differently in Teams, this would be the same as finding out about the role in a channel)
I know that I can get if a user is in a group through the optional group claims that are added to the ID token but this doesn't include the rule inside the group/team/channel.
To read a user's role in a channel currently requires admin consent, the permission needed is ChannelMember.Read.All see list conversation member documentation here. Admin consent is also required to get a member of a team or list members in a team. For your particular use case, I would recommend asking your admin to grant these permissions.
We are removing User, User Group and Permission models from our backend in favor of Auth0.
Our first idea was to just delete User, Group and Permission tables from DB and replace related foreign keys with varchar field. In this field we would then enter IDs that we get from Auth0 in JWT (pointing to something not present in our DB).
Is this good approach? I somehow feel that there must be more "relational" way of doing this.
Generally OAuth will not do all of the permission checks for you. Instead it gives you general mechanisms to sign the user in and issue + validate tokens.
In most real world architectures you also need to manage a second level of authorization in your back end - using domain specific user data for roles, permissions etc.
A couple of write ups of mine may help:
User Data Management
API Authorization
Auth0 Community Manager Dan here,
In this scenario you may be able to leverage the RBAC to replace your existing users/groups/permissions setup.
You would register a user's roles and the associated permissions of each role in the Auth0 dashboard or programmatically via the management API. Then you can setup a rule to add user roles to the token.
To connect this user to your existing user data store you can store the Auth0 id, similarly to how you have described.
This allows you to lookup the user when the token is received, and to associate any permissions or roles the user has. You can make roles API-specific by adding a prefix to the role, or have roles be general depending on your needs.
I'm trying to get a list of all users in my organization (~300), but the /users endpoint only returns two admin accounts.
Our administrator has given the application consent.
Scope: https://graph.microsoft.com/.default
Does it have something to do with the "(Admin only)" marking on the screenshot below?
/v1.0/users returns:
Some permissions do require an Admin Consent and thus have the marking "(Admin only)".
"Admin only" means that only an administrator can consent this permission.
Most delegated permissions (access on behalf a user) do not need an Admin consent, but some like e.g. Agreement.Read.All are only available for administrators.
Since you are using Application Permissions (and getting access without a user) all permissions will have the "(Admin only)" mark. But this does not mean that the returned results are limted to admins.
Seeing you have given the app the permission User.Read.All your app should be able to request a list of all Users with /v1.0/users/ (it will definitely return all users).
The most likely explanation for your results is that you only have two users in your Office365 AD.
Maybe there was an error setting up the users?
I would suggest to login into the Graph-Explorer and check if you get the same results.
And to check in your Azure Admin Portal if all users registered in your AD.
I hope you're fine, this is my first question and I really don't know where to start from, so here it is,
I've been trying to build a sample with Microsoft Web api Template where I have to authorize users based on roles for example "Admin, Moderators, etc..." so, the thing is the I don't want to put all those roles on the top of the controller like
[Authorize ( Roles ="Admin, Moderators, etc...")]
I see this as not a good practice because What happens if I create another role in my db? I will have to modify the controller to add the new Role xD, really bad, isn't it? so the question is. How to extend some class like AuthorizeFilter to get the roles from database and validate with the controller? I mean if there is a user who is in the role admin authorize it and viceversa?
the other question is How to build a great authorzationfilter which can manage something like if a user if in Moderator Role but the only right he has is to user the Create action in the controller?
I hope you can help me with an example...
Thanks in advance
Ps. Sorry for my english
I agree role based authorization is somehow limited and authorize attribute is a bit rigid.
In some scenarios role based authorization is not enough, you need to extend it. You can introduce the permission concept. Instead of be a requirement that you have to be a member of a specific role to execute an action, you could state that to be authorized to execute an action you need a specific permission. So instead of authorize attribute you use RequiredPermisionAttribute. Of course you need to write RequiredPermissionAttribute as an authorization filter.
In the database you have the Permissions Table, the RolesTable, the RolePermissions table and UsersInRole table.
So a user can be a member of one or more roles. A role can have one or more permissions. A user has a specific permission if he/she is a memeber of a role that has that permission.
The required permission filter checks if the logged in user is a member of a role that has the permission, if not, then returns 401 not authorized.
This is a more flexible approach, actions are not tied to roles and roles don't have a fixed number of permissions.