For our product we are currently storing customer credentials hashed in db (3 tier architecture) . We want the authentication to be done at 1st tier itself ,which aws solution can be used for this ,May be AWS HSM but what changes need to be done at app layer to do this .
This is a website
using cloudfront to route across across edge
using database replication
also we have active-active multi region .
any suggestions would be useful
thanks
I agree that some further details on your architecture would help. Is this a web application, mobile app, other fat client? How are you achieving the active-active multi-region architecture at the DB? I would like to suggest AWS Cognito but the multi-region needs become a bit more complex in that scenario.
Today how do you determine which region your users are routed to? If using AWS Cognito you'd likely need to create a user pool per region but this means your users would need to be routed to the correct user pool based on their region.
I have had great luck with AWS Cognito identities from web, mobile, and fat client apps and have even used many of the Lambda integrations with Cognito for commercial grade applications. Some good examples -
http://docs.aws.amazon.com/cognito/latest/developerguide/using-amazon-cognito-user-identity-pools-javascript-examples.html
http://docs.aws.amazon.com/cognito/latest/developerguide/walkthrough-using-the-ios-sdk.html
http://docs.aws.amazon.com/cognito/latest/developerguide/setting-up-android-sdk.html
Related
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.
Hi and thank you for your time!
I want to use a IDaaS for my project and Google Identity Platform is one of the options I was considering. One of the considerations is the availably of the service, so I am trying to come up with a solution for disaster recovery.
I can't seem to find information to answer my question anywhere in Google's doc: is Google Identity Platform region based? And if it is, is there a way for Google Identity Platform to support multiple regions in case of an outage?
For example:
Amazon's Cognito is region based and migrating/replicating user credentials from one region to another is not supported by Amazon. It is a manual process to replicate some of the data between regions. In the event the region hosting your Cognito user pool becomes unavailable, the user will have to reset their password when authenticating to the pool in another region https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-using-import-tool.html
Just wondering if Google Identity Platform will handle this more gracefully.
Thank you again!
is Google Identity Platform region based?
Google Identity Platform is global. Google describes this service as planet scale.
is there a way for Google Identity Platform to support multiple
regions in case of an outage?
Although Identity is global, the service is replicated to each region. Occasionally there is a region outage. For example in 2020 there was an outage. Google publishes details on service imparement. Example incident here. Service outage list here.
For example: Amazon's Cognito is region based and
migrating/replicating user credentials from one region to another is
not supported by Amazon. It is a manual process to replicate some of
the data between regions.
Google manages the service. There is nothing for you to do in the event of a region outage except for waiting for Google to bring the service back online. This does not effect other regions and typically the service continues to work globally except in the impaired region.
I am reading about multi-region architecture considerations.
Our reasons for moving to a multi-region architecture are pretty much the same as everyone else's:
Reducing latency for customers that are in different continents (EU, US, Asia, Africa)
Being in compliance with their data storage needs
Enable regional failover
We will be using Cognito pools and dynamo DB for data storage. Global Cognito pools do not seem to be a thing as Global DynamoDB tables. For a multi-tenant system SAAS system with tenants in different continents, Should the user pool be generated per region or per tenant? In this video here, https://www.youtube.com/watch?v=kmVUbngCyOw&feature=emb_logo&ab_channel=AmazonWebServices , it is recommended to have a pool per tenant. I fail to see many advantages for it though.
Is it instead a good idea to have a user pool per region instead?
The video also suggests having identity pools in addition to user pools. Why should that be the case in a multi-tenant system?
if I was to ensure data residency in the same region as the tenants in dynamodb as well, how should that be handled? and how should active-active architecture
We also need to host the application URLs like tenant1.companydomain.com for all of the tenants. what's the best way to go about it?
This question is too large, but anyway.
1. Reducing Latency
Unless you are calling Cognito APIs often Authentication is really the main concern here, but if you are using a long lived refresh token they shouldn't have to authenticate all the time so it wont be a massive problem. However a bigger problem is if you only use the one pool, you will have to consider that you sometimes need some Cognito Integration to be in the same region, such as a Cognito Authorizer on an API gateway. But you could write your own Lambda Authorizer to get around this.
2. Being in compliance with their data storage needs
This may force your hand in the User Pool decision, although you can always do the option of keeping your identity and your details in separate storage, making use of Lambda Triggers in the User Pool to sync data.
3. regional failover
I don't understand this in regards to your question about how many User Pools to use. If you use one in each region, then you will need to duplicate it in another region if you wanted to add your own failover capability. If you had only 1 User Pool you would have to duplicate only 1. I've never heard of anybody duplicating a User Pool to another region, this conflicts with what you wanted in 2.. If you've used integrations too, you cannot default to another User Pool you'd have to default to a whole new instance of the website, not just the User Pool. You'd have to also create your own Triggers which would do this for you.
Should the user pool be generated per region or per tenant?
This honestly is a large question in itself, we build a multi-tenant SAAS platform and I can honestly say User Pool per tenant would be a nightmare. 1 User Pool is easiest (as for example with the API GW Integration you cannot select multi user pools). You can use an app client per tenant and customize the signin for that tenant and give each tenant their own sub-domain.
4. Is it instead a good idea to have a user pool per region instead?
Other more meaningful questions are maybe? Do I want users to have the same identity in different regions? Do I want a user to be able to use more than on region? etc. Think about different websites that have this feature. For example Amazon you have a global identity and you can switch your store you are visiting, you need to specify requirements.
5. The video
Sorry not going to watch the video, but you can have an identity pool select permissions from the token (i.e. the group permissions for that user in Cognito). That covers 99% of use cases start from there.
6. if I was to ensure data residency...
Out of the box this is how the cloud is unless you specify a global resource everything is per region so you do nothing. You cannot have both data residency and regional failover at the same time.
One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/
We currently have a webapp running in AWS Region Ireland (service for the UK) and are planing to expand the service into the US.
In order to be sure that the US users get a low latency experience we are considering mirroring the AWS resources used Ireland in the US.
The data for the US users should be stored in the US region, the UK data in Ireland. (There is no need to report across both regions).
We are thinking of building a centralised login services that runs in the Ireland region. After successful login the user will be redirected to the region where his data is stored. (The login service has to know in which region the data is stored)
Has anyone built something similar? Any recommendation how to approach this?
Would Amazon Cognito support such a setup (if we build the login service based on cognito)?
Currently Amazon Cognito does not support this out of the box.
But if you use Cognito User Pools with Federated identities the credentials you get can be used in any AWS region. Along with that you can store a custom attribute for the user defining the region to which that user belongs and then redirect them accordingly.