So, I was trying to build IAM service like Amazon IAM, but simpler. Company has users, groups, and policies. As you can imagine users, groups, and policies has many-to-many relation between each other.
Actions:
Policies can be added to groups
User can be added to groups or policies
Now the issue is, if User try to login then I have to make 3 request:
Get group and policies from user partition
Get all policies form group in that list
Get all policies
Then I have to do 3 roundtrip for every login. Is there a better way to do this? or design the relations differently.
I would denormalize this.
The effective policy of the user should be an attribute in the user document.
The effective policy should be recalculated async after the user is added or removed from a group or a policy is attached/detached to/from the user.
Related
I am looking for advice on a not so particular situation.
I currently have roughly 20000 stores.
All stores have admins, managers and user roles.
An admin can create/manage any roles
A manager can create/manage only user role
A user can login and access custom functionality.
Any persona can be assigned to 1 or multiple store and can have 1 or multiple roles for that particular store.
Ie:
StoreA has userA as Admin and userB as Manager
StoreB has userA as User and userB as Admin
At first, I converted my stores to be groups. But since roles are binded to the group, I would have still have 3 roles for each group (20000 groups and 60000 roles - Group StoreA, Roles: StoreA_Admin, StoreA_Manager, StoreA_User, etc...). Not sure if it is the right decision, And I am not sure about the performance.
Then, I kept the stores as groups, but instead of creating roles, I created custom multivalued attributes that saves the group uid. That worked in carbon, as well as the API, but the console doesn't like the multivalued fields. And if another role is introduced, I would have to create another field.
Any thought on how to approach this situation ?
We can map your story to IS groups and roles as follows.
Please note that groups and roles are treated as two separate resources since IS-5.11.0.
Refer to:
https://is.docs.wso2.com/en/5.11.0/setup/migrating-what-has-changed/#group-and-role-separation
https://medium.com/p/93d42fe2f135
That separation is not clearly visible in the management console. So you can use the console application to create groups and roles.
Group used to represent a collection of users in the user store. One user can belong to zero or more groups.
Role is a collection of permissions. A role can have zero or more permissions.
We can assign a role either to a group/ a user.
Due to this statement:
A user can log in and access custom functionality.
We don't need to assign any role to normal business users specifically.No specific role is required to login into the business application via identity server basic authentication. In case your business application has a role-based access control need to assign a role to business users as well. Otherwise, every user will get login permissions upon successful authentication, it should be enough to do business operations in the application.
In your case, if any store's admin has the same set of permissions and any manager has the same set of permissions, you can't just evaluate the permissions and authorize the requests.
For eg: If user B is the manager of store A and admin of store B, he has inherited both admin and manager roles related permissions. But user B performs a request on store B, you have to authorize the request based on only the roles related to store B.
I am new to AWS...
We have a home grown user authentication and authorization.
We define authorizations(roles) in company terms, role1 allows you to do tasks1 and tasks2. Role2 allows one to perform tasks3 only.
I can see how I can use Cognito for my user/password management.
Unclear if I use cognito for roles verification, i.e authorization.
Thoughts?
In a Cognito User Pool one can define both Users and Groups, which can be leveraged to drive fine-grained RBAC permissioning. You can define a custom attribute in the User model (e.g., "department" or "role") and map this attribute to Groups.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html
Each group can optionally be associated with an IAM role, so it's possible to restrict access to AWS resources (e.g., certain DynamoDB tables) by group -- as an additional layer of security.
However, if you don't need/want to map users to different IAM roles, maybe just handle authentication completely from within your application.
I have users that have been added by other admins in my AWS account. I am afraid that these users might get deleted by other people.
Is there a way to add a description to an IAM user?
I don't see any way to add description/tag when you create an IAM user. One suggestion is to create a IAM group for each admin and add the user to the admin's group when a user is created/added. You can have group(s) with no policy attached.
There is currently no way to add a description to a user. There are a number of better ways to solve your core issue however. Some of the IAM Best Practices specific to your use case include:
Use AWS Defined Policies to Assign Permissions Whenever Possible - AWS-managed policies are designed to support common tasks, such as deleting and creating users. Assign these policies to the users that need them.
Grant Least Privilege - Granting only the permissions required to perform a task. Determine what users need to do and then craft policies for them that let the users perform only those tasks. This is probably the most important factor in preventing users from being deleted accidentally.
Monitor Activity in Your AWS Account - You can use logging features in AWS to determine the actions users have taken in your account, including deletion of users either accidentally or on purpose. Two very useful tools you should be using in this regard include:
AWS CloudTrail - CloudTrail provides event history of your AWS account activity, including actions taken through the AWS Management Console, including user deletions.
AWS Config – Provides detailed historical information about the configuration of your AWS resources, including your IAM users, groups, roles, and policies.
As you can see, utilising the built-in tools that AWS provides can assist you in preventing administrators from deleting users unnecessarily.
As a workaround, you can add a TAG to your user with its key named "DESCRIPTION" and put in the description as a value. Note that for the value, you are very limited to the characters you can use. For instance, you cannot use the apostrophe ('). But it is better than nothing.
Can I apply a policy (for example to an AWS DynamoDB table) but restrict it based on a specific field of the Cognito user (other than the Cognito id)?
What I'm tring to implement:
I've got multiple Cognito users that belongs to one specific group. Each group can have multiple users. There are a lot of groups > 1000.
Each group should have permissions to read/write rows in a DynamoDB Table that belongs to the group (to do so the table has a field GroupName).
Each user should have the same permissions that the group he belongs to has.
I would like to check in the policy file that MyCognitoUser.GroupName equals the row.GroupName
If you are using Amazon Cognito User Pools then you can use the recently launched Groups functionality to assign roles based on the user groups (you don't need to store this field in DynamoDB, instead it is part of user profile).
I'm attempting to develop an application architecture almost exclusively on top of AWS services.
This application has both User and Organization "entities". As one might except, a User may be an admin, role-x or role-y of one or more organizations. (role-x and role-y are just placeholders for some role with some set of specific permissions. A User may also be standalone (that is, not have a role on any Organization).
Our current thinking is to use DynamoDB to store organization and user specific data. For users this may include some basic information (address, phone number, whatever), and for organizations it may include fields like "mission statement", "business address" and so on.
An admin of an organization would be able to edit all organization fields, whereas a role-x might only be able to update "mission statement" while reading all other fields.
Since I mentioned that a single user may have roles on many different organizations, that might look something like:
user1:
organizations:
123: 'admin'
456: 'role-x'
789: 'admin'
It's also worth noting that these role assignments are modifiable. New or existing users may be invited to take on a specific role for an organization, and an organization may remove a user from a role.
This is a fairly straightforward type of layout, but I wanted to be very clear about the many-to-many nature of the user, org and roles.
I've been reading IAM and Cognito documentation, as well as how it relates to fine-grained control over DynamoDB items or S3 buckets - but many of the examples focus on a single user accessing their own data rather than a many-to-many role style layout.
How might one go about implementing this type of permission system on AWS?
(If policy definitions need to be updated with specific Identities (say, for an Organization), can that reliably be done in a programatic way - or is it ill-advised to modify policies on the fly like that?)
The above answer is outdated.
AWS has added Cognito-Groups recently. That provides more flexibility
You can use technique described in the article to achieve that:
https://aws.amazon.com/blogs/aws/new-amazon-cognito-groups-and-fine-grained-role-based-access-control-2/
Unfortunately the kind of permission system you are trying to implement is not possible with Cognito at the moment. With Cognito you can currently create unique identities for your users in an identity pool. Users can authenticate using any external provider such as Facebook, Amazon, Google, Twitter/Digits or any OpenId Connect Provider. Users can also authenticate through your own backend authentication process. After the user authenticates, Cognito creates a unique identity for that user. There’s a concept of an identity, but there’s no concept of groups. All users/identities within a one identity pool can get credentials from roles associated with that identity pool. Currently you can specify two roles: One role for authenticated identity and one role for unauthenticated identity. There’s no such feature at the moment where you can specify multiple groups for each identity and specify role on that group.
For more information on Cognito, you can refer to
https://aws.amazon.com/cognito/faqs/
http://docs.aws.amazon.com/cognito/devguide/getting-started/