We are using Cognito for managing the users for our saas-application (www.contempus.be) , and are very happy with the functionality it offers.
However, there are a few aspects that we think could be better, and we're wondering if there are any tools out there that can be used to easily manage users.
Do any third party tools exist to manage Cognito User Pools?
A few features we think would be useful :
Assign groups when creating users.
Set Custom attributes when creating users.
Search users by custom attributes
Are other people also interested in these features?
Thank You,
Dries
Related
I have a user, community and post type where a community can have multiple users and posts. The posts has an attribute called "visibility", if the visibility value is "private" only the users of that community can see the posts. If the visibility is "public" every user can see the post. Is possible to accomplish this using amplify and cognito? How?
Cognito has groups. You can create groups and add users into these groups. When your user authenticates they get a token, and the claims on that token can be used to confirm which groups they belong to.
Cognito Groups are really useful for controlling access to things like admin apis with an 'admin' group. However, if you're creating lots of groups of adding users in and out regularly, I would recommend implementing an application level feature (i.e. manage this in your database).
Cognito isn't as scalable as your application persistence is likely to be. It can be a bit slow and it doesn't come with nice features for managing your groups.
So yes, its possible to manage in Cognito, but I would recommend doing it with a database of some sort.
Question-
Is having a dedicated user per integration a personal choice or it is a good practice?
Background
We have about 5 different Integrations with Salesforce. Each integration serves different purpose and needs. e.g. one is a bidirectional sync, other is a 1 directional sync from external system to SF, yet another is a 1 directional sync from SF to external system.
Currently we have a dedicated Integration User for each Integration.
The reason as I understand is that, each integration user has different permissions, and also for whatever reason if we have problems with one user account, we do not want all the integrations to be affected. Having a dedicated user per integration also would allow us to better debug and mitigate issues.
Can someone suggest ideas as to how to decide - if it is better to create a new integration user or use the same user for more than one integrations.
I would say that the strongest arguments to reuse the same user for multiple integrations are:
User licenses are expensive and some organizations don't have many unused licenses.
It is easier to maintain a single user with a single profile.
However, I prefer having separate users per integration for some of the same reasons you already mentioned:
Security: each integration user has access only to what it needs and nothing else.
Ability to better isolate and debug issues that arise.
Personally, I like the approach of having a stripped-down integration Profile assigned to all my integration users and assigning permissions via Permission Sets; it makes thing easier to manage.
We are currently building a webapp, which has several user roles. Each user has one or more roles assigned, which grants them permission to interact with specific parts (REST resources) of the webapp. For example, a user with role admin is allowed to perform a create action on the resource user.
We have implemented this access control using RBAC with Casbin. This has suited our access control needs until now. We have arrived at the point where we have to implement some kind of mechanism, which enables users of our webapp to grant access to other users for specific data objects (for example their address). In some cases these other users also need to be able to mutate this data.
I have a feeling RBAC is not meant for this level of fine-grained access control. Therefore I am looking for best practices/alternative access control models which are suited for this use case.
I read about ABAC in this answer, but still have the following 2 questions:
Is ABAC still a recommended model, or are there other models I should know about?
If I end up using ABAC, what is the best way to combine this with RBAC?
I much appreciate any responses.
I'm Casbin author. Recently, Casbin adds support for scaling ABAC rules: https://casbin.org/docs/en/abac#scaling-the-model-for-complex-and-large-number-of-abac-rules. Now you can write very powerful ABAC rules within Casbin. You can also mix RBAC and ABAC together inside Casbin.
I know design is subjective. But I wanted to know if this is a good idea?
Suppose I implement OpenID connect in my application. I support sign in through multiple platforms. But now, suppose I need to maintain a database of my users for authorisation of resources on my server; or let's just say I need to store user preferences.
Is it a good idea to maintain a user's table and push data into it every time a user signs in using OpenID, or using my sign up/sign in API, using email ID of the user as the primary key (since that doesn't change) provided by OpenID?
What are some good ways to combine the two? What are some pros and cons of this?
What are the best ways to support authorisation (of resources on my server) along with authentication using OpenID/oAuth?
It is a really good question and not covered well in many places.
TRACKING USERS
In terms of sign in via multiple platforms a common pattern is to use the same authorization server for all types of login and 'federate' to different identity providers, with the following benefits:
Simpler code in your UIs and APIs
A single user id per user regardless of the sign in method
USER DATA
In the real world of business apps you often need to manage users and authorize requests via 2 sources of user data, as you indicate. A couple of my articles may provide some useful techniques:
User Data Management
Authorization Design
A precursor: I've worked now in two enviroments with conflicting principals on this. I am outlining the competing ideas and would like to know which is 'correct' given the scenario described.
Scenario: Multiple applications exist on our intranet. We are implementing OpenSSO with LDAP as our authentication control and user directory. The issue comes to play is, with the LDAP authentication we know a user is allowed on the intranet but to which applications is questionable.
We intend to use LDAP to control what applications each user can access i.e. helpdesk, consultant review, report generator, survey creator etc.
The question arises in that, within each application are a significant amount of roles, and the fact that people may have multiple roles.
What is the best way to address this second area? Shoudl ALL roles be in the ldap or just the application allowances with each app database containing the more granular roles?
One approach is to use LDAP to maintain relatively high-level role information, but keep the very detailed application-specific information internal to each application.
For example, an individual might be members of LDAP groups (roles) like "employee", "help desk associate", "help desk supervisor", etc., and then the individual applications would map the high-level roles into the application-specific functions. A particular high-level role might imply access to multiple applications, and different roles would have different levels of access.
For example, a "help desk associate" might be able to create tickets, but maybe only a supervisor can delete them or run reports.
This is one of those areas where there's no one right answer. Centralizing everything in LDAP gives you better ability to report/audit individuals' access, at the cost of complicating your central LDAP schema with a lot of application-specific data. Also, depending on what existing/commercial applications you're trying to integrate, the applications may not support pulling all their fine-grained access information from LDAP.