Me and my team are implementing a product based on microservices architecture(every microservice has it's own data storage). We already have a couple of services deployed on AWS and we need to add an ability to save user preferences like:
Saved filters to query data
UI widget settings
Columns order
etc
I think that we have the following options to implement saving user-preferences in my case:
Extend user profile(it is used to store companies and users, roles) service and add new items there
Create new microservice for keeping only user preferences
Use some of AWS services for that(I am still checking what is the best)
What we use for security:
AWS Cognito
SAML IDP
JWT tokens
We also have user-profile microservice(I mentioned earlier). It contains data received from other products like admin service.
What do you think? What is the best option for my case?
You can use custom attributes (as suggested by #jarmod) if you only use Cognito userpools. But if you use other providers like Microsoft ADFS, Google, Facebook etc., you could look into Cognito Sync. Although Cognito Userpools now support some external providers, it may not be suited for your use case. So, you could integrate various Auth providers (including Userpool) in an Identity pool and use Cognito sync datasets to store preferences. In fact, that is the whole point of Sync, to provide cross device access to small datasets like user-preferences. This way if a user logs in with Userpool & later with Facebook, you could give an option to link both accounts in your application & merge the user preferences. It all depends on your use-case.
Related
I am trying to make an API using AWS api-gateway and lambda.
Requirements
I am trying to build a dashboard, The dashboard will be for multiple organisations and each organisation will have multiple users who can login and see the respective dashboard.
Example we have a dashboard for Intel and its accessible by User1, user2, user3
A user must be able to login and access the dashboard for his specific Organization and also do CRUD on his data as well
I found out that aws cognito with its user pool can be used for the auth process. After that I intend to use api-gateway with lambda function to query a sql database and populate the frontend. The place where I am stuck at is how do I link the user from cognito to corresponding data in database.
In simple applications we would have a user-table and its a simple query but I would appreciate if someone can suggest a good way to go about implementing this
We have a site for our customers to log onto to get their relevant data. We have set it up on AWS using Cognito for user authentication. Each customer navigates to the same URL, enters their credentials, and then gets shown their own information. One of our customers has a corporate policy for any SaaS offering requiring a SSO (using SAML2.0). Our other customers do not need the SSO mechanism.
I have read through the documents AWS provides: (https://docs.aws.amazon.com/singlesignon/index.html) but these appear to be focused on a single corporation with AWS accounts for services provided by AWS. I have not been able to find any articles that address the situation.
Specific questions I have:
Is the AWS SSO mechanism the correct mechanism to use to achieve the goals? I have read in one Q&A that it is better to manipulate this through Cognito (but I cannot find the relevant article to link here).
If we set up one company to use SSO, can other companies use the credentials we set up to go to the same site?
Can we set up multiple companies to use the SSO separately, or will the application of a second SAML overwrite the first? (this doesn't seem likely as their would be updates to applicable users).
Any articles that can help point me in the best direction is greatly appreciated
AWS SSO would be a different AWS service you would have to integrate your application with.
If you're already using Cognito, you should be adding their SAML provider as a Cognito identity pool instead of adding AWS SSO.
I'm doing some analysis for a customer regarding multiple end-user applications they run. Right now, both have a separate user databases and now want to provide an SSO experience.
They threw out a bunch of SSO providers, specifically the new AWS SSO service. From reading what AWS SSO, my question is, AWS SSO seems more applicable for managing internal users for a company (ie using the same credentials for JIRA, sharepoint, and their company portal) and not really applicable for handling hundreds of thousands of end-user customer accounts.
Is my understanding of the purpose of AWS SSO correct? Like, I'm sure AWS SSO could work with end-user clients, but is that the applicable use case here? Is there a better SSO provide in this case to deal with SSO for end users?
Definitely, is not a good choice for end-users.
This is the entry splash at AWS Console.
Before you can start managing SSO access to your AWS accounts, you must go to the AWS Organizations console and create an organization with All features enabled. For more information, see AWS SSO Prerequisites
Look at this splash from AWS Console
AWS Organizations console and create an organization
That phrase explains what target was created for. So you're right:
AWS SSO seems more applicable for managing internal users for a company (ie using the same credentials for JIRA, sharepoint, and their company portal) and not really applicable for handling hundreds of thousands of end-user customer accounts.
I recommend you to use AWS Cognito as Single-sign-on
Using Cognito you will have a few challenges:
The problem would be passing token(with an expiry value) from site A to B securely. There is no built in SSO facility provided by Cognito. You would have to manage the encrytion, storage & transfer of tokens yourself. Reference: How to use AWS Cognito as Single-sign-on?
Take a look at this post:
Use Amazon QuickSight Federated Single Sign-On with Amazon Cognito User Pools
Hope this gives you a little more information to accomplish your scenario.
Assume I have a web app application and I use aws cognito users-pool to manage my users. Also assume some of the users are just "Guests", some are in a "Regular" paid plan and some are under "Premium" paid plan.
Where is the best place to store the users plan information? Is it better to store it as a Cognito user attribute or in some key:value DB (e.g Dynamodb)?
How should I control what a user can do according to his plan? Should i check the user ID against his "plan type" value in Cognito user pool/DB for each http request he makes to the server? Is there a cheaper (resource wise) way to accomplish this?
Thanks
If your application is single tenant and you are using the particular Userpool only for this application, you can store the 'plan' in an custom attribute.
This would be difficult to manage if you use the same user pool for multiple applications or having multi-tenancy with different 'plans' for a single user.
To store the plan you can use either Dynamodb or Cognito Sync Storage.
I'm trying to use AWS Cognito for my company where we have different applications with both in-house and client access. The following are few of the requirements:
List all users in the console (view email, last-login etc)
Limit access to users of specific domains
Assign roles and permissions to different users
Assign roles in console or via. API
Issue access tokens containing username/roles/permissions
Decode access token in the app and to allow/deny access based on roles
Send email notifications for the current user from within the app
I was assuming that AWS Cognito was a general purpose authentication/authorization solution, with APIs that could be tailored to any auth needs. Any suggestion is appreciated.
Thanks in advance,
Cognito covers a lot of what you described in your use case description and sounds like it might suit your use case. However without a concise question, it's very hard to give a good quality answer.
I suggest you check out the Cognito Docs, and then come back with any clarifying questions that you have.
https://aws.amazon.com/cognito