My goal is to use Okta SSO integrated with AWS SSO to integrate all user Sign-in and permission management for AWS resources from the Okta, using accounts configured on Okta.
I also want it so that each user on Okta has their own Amazon Workspace Windows instance using their Okta credentials.
I currently have a Simple AD (Directory Service) configured on the AWS account, exclusively for Amazon Workspaces access.
Is this a possible goal that can be achieved using OKta, AWS SSO and Directory Service? After going through each of their documentations I am still not clear if these services have the capability to integrate this way.
Any Advice would be appreciated.
There are two topics in this question.
AWS SSO:
There is a standard integration in the AWS Documentation.
https://docs.aws.amazon.com/singlesignon/latest/userguide/okta-idp.html
AWS WorkSpaces:
You mentioned that you use currently SimpleAD, in case you want to switch the IdP for your WorkSpaces you should be aware that you need to re-provision the WorkSpaces. I've not as much experience with OKTA, but I think there are two options.
In case you've already a Active Directory you should be able to integrate it with WorkSpaces (AD Connector or AWS Managed AD with forest trust)
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust.html
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html
In case there is no pre-existing AD, you should be able to sync the users with a AWS Managed AD.
https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-integrate-existing.htm
OKTA MFA integration for WorkSpaces:
https://aws.amazon.com/blogs/desktop-and-application-streaming/integrating-okta-mfa-with-amazon-workspaces/
Related
I'm working with developers who have recently moved over to Google Workspace for business communications. They are relying on Jenkins for build automation. They also have team-limited AWS console access, access to CloudWatch logs and SSH access to some EC2 development hosts running docker containers. We are considering using the Google account for federated sign-on to Jenkins and to AWS SSM Systems Manager, which will replace the SSH host access. Access will be restricted by team, so some form of group-management is important.
For the Jenkins access, I have followed this document to use Google federation and Amazon Cognito: https://www.tech-notes.net/jenkins-login-with-cognito-in-aws/
The groups can be added into AWS Cognito groups within the userpool and mapped into Jenkins oic-auth plug-in as "cognito:groups".
For the SSM Session Manager access, we could use identity federation for a Google login into the AWS account ... and then user IAM groups and IAM policies. However, we would already require groups management within the Cognito userpool (i.e. double the admin). So could either userpools provide the SSM access permissions? Or could the users present in IAM somehow be present for Cognito too?
We would also consider the alternative solution of not using Google federation if the AWS IAM user accounts could be mapped to log into Jenkins using AWS credentials ... but I can't see how this would work.
Many thanks.
I was wondering if I could use AWS organisation and AWS SSO to provide access to AWS services to someone without an AWS account.
Is it possible using the above mentioned services or some other way?
AWS SSO could be used which would utilise the credentials of whatever Identity Provider you can connect to SSO i.e. OKTA/Active Directory etc.
With that setup an AWS account would not be provided as their access would be assumed through a permission set/role you create, and they can consume AWS services
https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html
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.
Is there a way to interact with the AWS SSO service using the AWS-SDK?
https://aws.amazon.com/single-sign-on/
I am just looking for programmatic access to AWS SSO - with the AWS CLI or with the SDK or anything really.
Unfortunately there isn't. There is however an open issue on the AWS CLI for this - go there and upvote, that's probably the only way to make this happen.
https://github.com/aws/aws-cli/issues/3447
4/21/2021: Take a look at the AWS SSO documentation. There is now an API to manage permission sets and assigning them to users: https://docs.aws.amazon.com/singlesignon/latest/APIReference/welcome.html
Here's the blog on this feature that supports this API:
https://aws.amazon.com/blogs/security/use-new-account-assignment-apis-for-aws-sso-to-automate-multi-account-access/:
"AWS SSO recently added new account assignment APIs and AWS CloudFormation support to automate access assignment across AWS Organizations accounts. This release addressed feedback from our customers with multi-account environments who wanted to adopt AWS SSO, but faced challenges related to managing AWS account permissions. To automate the previously manual process and save your administration time, you can now use the new AWS SSO account assignment APIs, or AWS CloudFormation templates, to programmatically manage AWS account permission sets in multi-account environments.
With AWS SSO account assignment APIs, you can now build your automation that will assign access for your users and groups to AWS accounts. You can also gain insights into who has access to which permission sets in which accounts across your entire AWS Organizations structure."
I would like to share this tool that I did using docker. https://hub.docker.com/r/javiortizmol/aws_sso_magic
The image contains:
aws cli v2.
Python 3.9.
aws-sso-magic
Or just install it from pypi.org https://pypi.org/project/aws-sso-magic/
both of them are used to authorize from company network to use AWS resource. I do not know what is the difference btw them.
AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as AWS Microsoft AD, enables your directory-aware workloads and AWS resources to use managed Active Directory in the AWS Cloud. The Microsoft AD service is built on actual Microsoft Active Directory and does not require you to synchronize or replicate data from your existing Active Directory to the cloud.
see https://aws.amazon.com/directoryservice/
whereas STS:
The AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).
see http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html
The AWS Directory Service is a full AD implementation which can "join" your in house servers. This would work better if there is a VPN and/or AWS Direct Connect in place. So replication occurs just as it would if you set up another Microsoft AD server
STS for linking your on premise accounts to AWS has some kind of shim software that is custom, running on premise. In the case you are asking about the local on premise environment has AD. The custom software deals with authentication against a local AD, then negotiates temporary creditials with the AWS account. AWS do custom software for this use case see https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/
So the difference between them is
AWS Directory Service sets up a new server on the cloud. This has to be linked to your on premise equipment to get it to work. It works better with a good link between on premise and AWS. Could be a better fit if your are running Microsoft stack on AWS
STS in this use case requires installing software on your on premise systems. There is also configuration to the AWS account