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.
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.
I am just starting to use GCP and I have some questions about the service accounts.
Say there is a team of like 4 remotely located developers and we all want to use the python API to access GCP to launch instances and run stuff on them. My question is should every user get their own service account and keys or should one service account be shared by all? What is the intended use case here?
Google Cloud Service Accounts provide both identity and authorization to Google Cloud.
They are similar to user accounts. If you would like to do auditing or logging of actions with service accounts, you will want to use separate service accounts per user.
Service accounts are typically used for software applications to authorize their actions with the Google Cloud APIs. Service Accounts are using to issue OAuth 2.0 Access Tokens and optionally OIDC Identity Tokens. These tokens are what provides your application with authorization in Google Cloud.
My question is should every user get their own service account and
keys or should one service account be shared by all?
Yes, you should issue separate service account JSON key files to each developer. In the same way that you would not share usernames and passwords for computer systems, you would not share service accounts.
I have written a bunch of articles on Google Cloud Service Accounts that might help you understand how to configure and use them:
Google Cloud Service Accounts
From AWS docs:
When to Create an IAM User (Instead of a Role)
...
You want to use the command-line interface (CLI) to work with AWS.
When to Create an IAM Role (Instead of a User)
- You're creating an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and that application makes requests to AWS.
- You're creating an app that runs on a mobile phone and that makes requests to AWS.
- Users in your company are authenticated in your corporate network and want to be able to use AWS without having to sign in again—that is, you want to allow users to federate into AWS.
But it seems like companies heavily use roles for everything:
Role for groups by creating roles with specific policies and creating custom policies to apply to groups.
Assume role to use the CLI.
Switch role to use different accounts.
Is that excessive or real work based solution?
Is that excessive or real work based solution?
Based on my own experience with AWS, heavily using roles is a real work based solution because, in my company, we use only roles to give access to users (yes, we have 0 users registered in your AWS environments). I'll list the reasons why we chose this way:
We are using AWS Control Tower.
This service enables AWS Organizations with at least 3 AWS accounts to manage your organization. It'd be a mess with we had to create a user for each AWS account. Also, AWS Control Tower enables AWS Single Sign-On.
We're using AWS Single Sign-On.
This service correlates multiples AWS accounts with multiples roles with multiples users. Description:
AWS Single Sign-On (SSO) is a cloud SSO service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications. With just a few clicks, you can enable a highly available SSO service without the upfront investment and on-going maintenance costs of operating your own SSO infrastructure. With AWS SSO, you can easily manage SSO access and user permissions to all of your accounts in AWS Organizations centrally. AWS SSO also includes built-in SAML integrations to many business applications, such as Salesforce, Box, and Office 365. Further, by using the AWS SSO application configuration wizard, you can create Security Assertion Markup Language (SAML) 2.0 integrations and extend SSO access to any of your SAML-enabled applications. Your users simply sign in to a user portal with credentials they configure in AWS SSO or using their existing corporate credentials to access all their assigned accounts and applications from one place.
Please, check out some features offered by this service. There are a lot of benefits using roles instead of users. In my point of view, with AWS SSO, AWS itself facilitates the use of roles.
The only disadvantage I found is that every time I need to use AWS CLI, I need to access AWS SSO portal, copy the credentials and paste in my terminal because credentials expires after some time. But in the end, this disadvantage is small compared to the security that this process offers - if my computer is stolen, AWS CLI couldn't be accessed because of credentials expiration.
I am setting up an AWS Account, the account will be used by an organization of employees for EC2 use/experimentation. Obviously, I do not want to distribute the root login info or set up one single IAM user for everyone to use. Unfortunately, I do not have the time to manage creating individual IAM users for everyone on a regular basis.
So, is there a way to auto-create IAM users based on a given email's domain on their first login attempt? The users should have read-only roles to begin, then an Administrator could give more roles as needed to each user. I am open to suggestions, perhaps lambda functions or linking to an identity provider?
Keep in mind that these new IAM users need to have access to the AWS Management Console, this is not necessarily intended for login to applications hosted on AWS.
Update:
Moving forward using this AWS Management Console Federation Proxy Sample found in Amazon's code reference, using with Microsoft Exchange hosted email.
If your existing identity provider supports SAML2 Federation, you can set it up to login to the AWS Management Console.
For more details refer Enabling SAML 2.0 Federated Users to Access the AWS Management Console.
Else you can implement a custom Federation Broker to return an URL to the user, after they authenticate with their corporate credentials.
For more details refer Creating a URL that Enables Federated Users to Access the AWS Management Console (Custom Federation Broker).
I'm considering AWS IAM vs usual ACL (django-guardian, passport.js, ...) to manage permissions and monitor the costs per user on my current project.
I wonder if IAM can be used to manage authorization of the application users or if it is only aimed to the developer team ?
Is there some examples of people using it this way on a regular basis ?
Is it a good practice ?
Will there be some caveats or hard limitations? (if you've experience it)
I already found this 2 years old answer : Should you use AWS IAM roles and permission for application users? but it lacked a return of experience on this question
You can use AWS Cognito UserPools with Users and Groups feature to handle both authentication and authorization of your web application.
For more information refer the Amazon Cognito Groups and Fine-Grained Role-Based Access Control blog post by AWS.
IAM is mainly built to provide authentication and authorization to AWS Services but not for web application. Because of this, it will become challenging to use IAM for web application authentication and authorization.
I recommend AWS Cognito instead.
IAM is suited better for developers and applications/services.