I am setting up our telephony system in AWS and we're utilizing AWS Single Sign On for our primary SAML authentication. This has worked fine for normal cli and console access but has kind of been a struggle for implementing Amazon Connect through the SSO Cloud Applications configuration.
Background
I have done a proof of concept with a single Amazon Connect instance and was able to federate login with a number of different permissions sets to simulate admin, developer, and user access for the single instance. This worked fine until I started adding additional instances and each time any user permission set tries to login to Amazon Connect they get Session Expired on the Connect screen.
Our setup is as follows:
Root account contains AWS SSO Directory
Dev Account has 1 Connect instance in the east
QA Account has 2 Connect instances total in east and west
Prod account has 2 Connect instances total in east and west
A lot of the documentation I've been reading seems it assumes the Amazon Connect instances are in the same account as the Amazon SSO service. Additionally the documentation mentions creating additional IAM Identity Providers for each Amazon Connect instance's SAML Metadata file, and a role associated that allows the SSO user to access that instance. I see where this would work in a single account, but I don't understand how to adopt the access role and implement it as a permissions policy in AWS SSO for the user group thats logging into the instance.
I've configured everything as close as possible to the Amazon Connect SAML Setup Guide, and I'm working on troubleshooting the permissions policy stuff to configure access, I'm just at a loss.
If anyone has previous Amazon SSO experience, or has done something similar with Amazon Connect that would be greatly appreciated. I just want to be able to validate whether this is feasible in the current iteration of Amazon SSO (granted its a newer service), or we need to architect and integrate a 3rd party SSO for Amazon Connect.
Thanks!
We recently have this kind of setup and requirements and still in the testing phase but so far, it is working as expected.
In the Amazon Connect SAML Guide that you linked, there's a lacking piece of information in there with regards to the Attributes Mapping (Step 10)
Change From:
Field: https://aws.amazon.com/SAML/Attributes/Role
Value:
arn:aws:iam::<12-digit-account_id>:saml-provider/,arn:aws:iam::<12-digit-account_id>:role/
To This:
Field: https://aws.amazon.com/SAML/Attributes/Role
Value:
arn:aws:iam::ACCOUNT-ID:saml-provider/IDP_PROVIDER_NAME,arn:aws:iam::ACCOUNT-ID:role/ROLE_NAME
Sample Value:
arn:aws:iam::123456301789:saml-provider/AWSSSO_DevelopmentConnect,arn:aws:iam::123456301789:role/AmazonConnect_Development_Role
The Setup:
Root AWS
Configured with AWS SSO
In AWS SSO page, you can have 1 or more Amazon Connect Applications here
AmazonConnect-Development
AmazonConnect-QAEast
AmazonConnect-QAWest
Dev AWS:
You have setup Amazon Connect
AmazonConnect-Development as the Instance Name (Record the ARN)
Create a new Identity Provider (for ex: AWSSSO_DevelopmentConnect)
Create a Policy (to be attached in the Role)
Create a Role (for ex: AmazonConnect_Development_Role)
See more here for the content of Policy
In Root AWS, configure your AmazonConnect-Development application to have the Attribute Mapping pattern same with my above example value.
You also specify the Relay State URL for you want the users to be redirected to a specific Amazon Connecct application.
xxx AWS:
Same steps will be applied as the above
Key Points:
For each AWS Account:
You will need to Create Identity Provider, name it with a pattern
Create a Policy to be attached in the Role
Create a Role and Choose SAML 2.0 Federation
Checked: Allow programmatic and AWS Management Console access
Link the Identity Provider with the Role
For the Applications that you configure in the AWS SSO page, make sure the additional Attribute Mappings have the correct value
Related
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 have created aws - elasticsearch instance in aws. It has a link of kibana. I want to give access to specific person.Such that only that person can access that link .What can I do?
I can allow IP specific access but that is very generic and IP keeps changing every time.
You can find a walkthrough on the AWS blog to use Cognito for access control to Kibana on AWS ElasticSearch, complete with IAM policy samples and AWS console screenshots showing you where to click.
The summary is this:
Create a user pool in Amazon Cognito
In the ElasticSearch console, select the checkbox for "Enable Amazon Cognito for authentication" and tell it to use your user pool.
Create a Cognito user and a group which you will use to access Kibana
Update the policy on your ES cluster to allow members of the Cognito User pool to assume an Auth role for the ES cluster.
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).
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.
I've been looking in to getting the AWS (web) console hooked up to an AD or ADFS setup for managing users. It was reasonable easy to get working with a SAML Identity Provider in IAM and some existing ADFS infrastructure.
The problem is that users that authenticate that way, as opposed to normal AWS user accounts, don't have any way to have associated access keys so far as I can tell. Access keys are a key concept for authenticating stuff such as the AWS CLI, which needs to be tied to individual user accounts.
What are the workarounds to allow a user authenticated via a SAML identity provider to still be able to easily use the aws CLI? The only thing I've come up with to far is some hacky crap that would proxy the aws cli command, request temporary 1-hour credentials from the aws STS service, put them in the aws credentials file, and forward the command to the normal AWS cli. But, that makes me want to throw up a little bit; plus, I have no idea if it would work if a command took over an hour to complete (large s3 uploads, etc..)
Suggestions? I would try the official Directory Service AD connector, but my understanding is users still just assume IAM roles and would ultimately have the same problem.
https://github.com/Versent/saml2aws was created to address this, and has a vibrant open source community behind it.
I've had success with aws-adfs for AWS CLI via ADFS
The repo owner is currently adding support for DUO MFA as well.
It works by authenticating the user to the same page you'd use for console access then scraping the roles available. You choose a role and then aws-adfs sets the default user to the credential set needed for sts access.
After the default user is set you can cli like normal: aws s3 ls
https://github.com/venth/aws-adfs