Support multiple login sessions for a single start url #2374
Comments
kdaily
added
guidance
|
Hi @tikicoder, The standard use case here is that all of your profiles that are SSO-enabled are using the same portal login. Each of your profiles can be configured separately to access different accounts or roles that each use the same SSO portal with whatever login credentials you use (hence the same Do you mean if you had two different sets of SSO portal login credentials (e.g., whatever you do through the browser to authenticate), and each one provided different sets of accounts and roles to access? In that case you would need to logout first (like As is, this would be a feature request, but if you can provide more details about your scenario that would help others decide if this fits their use case as well. Thanks! |
kdaily
added
feature-request
|
Sorry for not providing more of an example. So if I run it will prompt me for the information region, SSO Start URL ect, and it will have me log in. Lets say this is my admin This is the first profile I created with sso start url of I then create a second profile, with limited permissions. The issue, to me is more of a security risk. So now when you are logged in it creates 2 cache files then it creates another hash, and it looks like it is partially based on time. All the code I have seen when I run this command via a profile via cli or sdk, it all seems to have similar code It looks for a hash file of That is why I labeled it as a bug and not a feature. It is possible I missed code so it is referencing the correct cache file, but all the code I have seen to determine what cache file to use is only referencing the lookup around the SSO URL |
github-actions
bot
removed
the
response-requested
|
Hi @tikicoder, Thanks for the further details. There are two separate caches in use here. The first one is for the SSO login, which stores an access token and is indexed by the SSO portal start URL. By default, this is stored in |
|
@kdaily That makes sense. However, the credentials that are generated in the ~/.aws/cli/cache/ are based off the SSO. So those in there the cli creds should expire first, or if someone deleted the cli cache. Wouldn't the new cache file use the logic from above and determine the cache file is based on the sso url name? So when it went to regen the token it would find the cache file based on the url and give the creds from the admin setup because that has the hash based on url? If not isn't that what the sdk is doing, or am I missing some logic? When cached info expires cli experation (update - 2021-05-05 17:05 UTC) |
github-actions
bot
removed
the
response-requested
|
Thanks for the followup. There are so many users and accounts in these scenarios, so I want to clarify what you're expecting. For definitions, account means AWS account; user means SSO portal user; profile means the named profile in the configuration file; role means the SSO role set up for a user. Here's the use case I set up. I have a single AWS account. I created an SSO portal and two users, If I log in as The converse is true as well - if I log in as Is your scenario the same, or is there a account/user/role that is changing differently? |
|
Its is similar so keeping with your example. log in to both userOne and userTwo Both users should be logged in If you look in ~/.aws/sso/cache there is only one file. when running edit the ~/.aws/config using your text editor of choice then run userTwo is now an Admin, because userTwo is using the SSO from userOne to generate its token/creds They way around this would be to have different start urls, so the sso cache file is different, just adding / is enough but that only gives you 2 different profiles. Another example using python session_default = boto3.session.Session(profile_name="savvasSSODefault") default_client = session_default.client("sts") print("main \n{}".format(default_client.get_caller_identity())) |
github-actions
bot
removed
the
response-requested
|
I think there is confusion about "user" here. You've got "user" as part of the profile name, but a profile configured for an AWS SSO role does not and cannot represent a particular human. The profile represents an IAM principal that a human, who has logged in via AWS SSO, can get credentials for (if they have access to it, as configured with AWS SSO assignments). So different humans can use the same profile, but not at the same time, because only one human can be logged in for the CLI to a given AWS SSO instance (i.e., a given start URL) at a time, for a given local machine user (i.e., a given home directory). Once signed in to AWS SSO, that human can use multiple profiles (i.e., accounts and roles) without needing to log in again. If a different human needs to use the same computer (with the same home directory, i.e. the same Note that the account and role specified in an profile can only be used if the signed-in human is granted access to it through AWS SSO. So changing the role name in a profile has no effect on the access that the human is granted. You've got the phrase "userTwo is now an Admin", which is not correct. The human is now an Admin when using the "userTwo" profile, though the name "userTwo" is not a good profile name; it should have been "Data" (or similar) after the role it was configured to use. If the human has not been granted access to the Admin role through AWS SSO, this profile will not work for them! You're right that this could cause confusion, if I changed a "Data" profile to use an Admin role instead of a Data role, or more seriously, if I changed the account in a "Data-Dev" profile to the Prod account, I could get a user to accidentally make changes to Prod, but the assumption of the AWS CLI is that the user is responsible for the security and integrity of their Part of the problem here is that So while it seems from looking at the command that you're logging in to the specific account and role, it's only use the profile to get the AWS SSO instance (because that's the only configuration the AWS CLI knows how to use). You do not need to call Suppose you have the following [profile my-profile-1]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-east-2
sso_account_id = 123456789012
sso_role_name = Role1
[profile my-profile-2]
sso_start_url = https://foo.awsapps.com/start
sso_region = us-east-2
sso_account_id = 123456789012
sso_role_name = Role2So if you do If you then call If a new person, Mx. Jones, wants to use the same machine (with the same home directory), they need to be signed out in the browser first, so going to This is the intended behavior. The expectation for the CLI is that one human is logged in at a time, just like in the browser. If Mx. Jones wants to log in to the AWS console in the browser, they will need to log out of Mr. Jones's browser session (or more properly, Mr. Jones should have logged out when he was done using the machine 😉). The UX problem here is that the CLI login command looks like it's logging in to a specific profile, even though that's not its purpose (and logging in to a specific profile is not a needed operation, because the CLI and SDKs* are capable of getting and refreshing credentials for an account+role the user has access to through AWS SSO at the time of usage). The reason the CLI login command looks like this is that there's no current way to specify an AWS SSO instance (start URL and region) in any form other than a full profile. I have an open issue on that with the CLI here aws/aws-cli#5727. In my command line utility * Note about the SDKs: not all SDKs have support for using AWS SSO configuration. For the ones that don't, |
|
@benkehoe When you sign in with either my-profile-1] or my-profile-2 1 sso token file is generated. So the last one logged in is the active token for BOTH profiles. To your point The token is associated with a role that has permissions ABC. So If my-profile-1 has a role with more permissions and its logged into last the token file generated that both profiles use will be using the last token generated. The cached file for SSO is based on the start url If you create both profiles like you mentioned and then look You can log into both profile but there is only 1 cache and if you watch the cache file is updated as you switch profiles. |
|
The token in Let me put it this way: imagine instead that the command was The CLI makes an explicit assumption, just as the AWS web console does, that there is one human using the system at a time, and therefore when they are logged in, they have access to all the things they have access to. The purpose of AWS SSO is that you should only have to enter your credentials once, i.e., sign on a single time, to use all of AWS that you have access to. With the assumption just mentioned, this is not a security problem, just as in the browser. I think what you want to argue is that it is confusing that a profile is the input to |
|
@benkehoe I do the same It now uses the token from my-profile-2 its been a couple hours and I run not thinking about it I run what happens? aws ec2 describe-instances --profile my-profile-2 will use the token from my-profile-1 I have done the above and not had any issues running any commands. Unless I am mistaken, once you have the token/secret. How you logged in doesn't matter, or how it was generated doesn't matter. You have it. You have access to whatever that combination has access to. But at the end of the day when you have 2 profiles with the same start url they share the same cache file. In doing so, unless again there is anther validation that happens, they will share the same token/secret. Which that really is what matters. If you haven't tried it and have sso try it. Check the cache file. You will see you only have 1 regardless the number of profiles you create. Try running commands they should be using the token/secret for the last profile logged in with that has that start url. look at the code link below, you can see that it uses the start url for the hash. If aws doesn't feel its an issue or a feature request they can close it. Or if you have power you can close it. To me, could just be me being stubborn, multiple profiles with the same start url all share the same token/secret. The last one logged in is the access you have. |
|
To repeat, you are misunderstanding the relationship between the token in You are saying the expected flow is: but this is incorrect. The intended flow by the AWS SSO and CLI teams is: The entire purpose of AWS SSO is that the The cache entry in When you say "The token for both profiles share the same file and there is nothing in the file to separate them." you are misunderstanding the design of the system. Instead, think of it this way: "Both profiles share the same start URL, so they are both able to use the token for a session with that start URL to get credentials for the role in the profile". You fed this start URL to It would be less confusing if the flow was: which is essentially what's happening. |
|
"The entire purpose of AWS SSO is that the aws sso login call only needs to happen once, for any profiles with the same start URL. I am fully onboard with the fact that it is confusing that the input to aws sso login is a profile, because it appears to indicate that aws sso login should be called once for each profile that is being used, but this is not the case." If it only needs to happen once, then how do you set different permissions. My point the problem with that logic is you could have multiple profiles so you are using least permissions. I could have user a or user b. User b could be my day to day user and have separate login information. User a could be my I need admin access to do something. So I only log in when needed. With the logic above that can't happen. I understand why its happening I strongly disagree with "The entire purpose of AWS SSO is that the aws sso login call only needs to happen once, for any profiles with the same start URL." Since you could have 5 different profile for 5 different users all in your same setup for various scripts. Each user could have its own set of permissions. So that means to run each script you would have to log in before each script, or run the risk that you are using the wrong information. I will stand firm on this, and we will have to agree to disagree. Call it what you like but the ability for multiple accounts to use the same cred is a security issue. You are asking for a script to get ran with permissions it shouldn't or people are running with higher permissions then they need. Again to your point, "The entire purpose of AWS SSO is that the aws sso login call only needs to happen once, for any profiles with the same start URL". To me that is a horrible fundamental flaw in the system. If you have 5 profiles all with the same start url with 5 different role_names (since profiles are not tied to a user but a role) do you except that you can log in with 5 different users if you want or do you expect that the system just wants you to log in once. For me they are separate profiles and should be treated as such. The start url is a horrible way to group them. If they were grouped by start url and role name at least then you could be ensured that if you are using multiple users for each role, they are not sharing. We will have to probably agree to disagree on this, but AWS @kdaily or anyone else can close it if they want. |
|
When you say "you can log in with 5 different users", I don't understand what you mean by "users". There's the human, and there are the roles that the human can assume. If we think about the browser, you log in once through AWS SSO using your start URL, and you get to a page that lists all the accounts you have access to, and all the roles under each account. You can click "management console" under each of those roles, and a new tab pops up, giving you a console session with that role. You can return to the tab and click "management console" for a different role, without signing in again, or going to your start URL again. This open tab with all of your roles is like what you have after calling When you say "multiple accounts use the same cred", again I don't understand what you mean by accounts. Multiple people aren't using the same SSO token, nor the same AWS role credentials. A single person is using multiple IAM roles, which may be in the same or different AWS accounts. |
|
Lets say I have 2 logins I have 2 profiles When I do when I login as admin I use the user each user only have access to a subset of roles. The admin has full access to everything. The default user only has limited access to the things I normally need to do. Under what you describe. Each user would return its own token and have its own roles to limit what you can do. |
|
Those different emails would be different users within AWS SSO, which means they do not share the same permissions. The user id for [email protected] could be granted the Normal role, and [email protected] could be granted the Admin role and not the Normal role. When you call Note that Note that if you do the following though: if you have not signed out of AWS SSO in your browser, by going to the start URL and clicking "sign out" (and, if you're using a federated identity provider, you need to sign out of that too), you won't get the chance when doing the second All that said, this is not really a "single sign-on" setup, if you are using multiple email addresses for the same person. AWS SSO has been designed with the assumption that a given person has a single identity in the system, and so I think there's going to be friction if that's not true, which makes it valid to complain about that friction (e.g., that it takes a bunch of clicks to actually get fully signed out in the example above) Edit: it actually looks like if you aren't using a federated identity provider, |
|
Again agree to disagree about its not single sign on. The point of single sign on is to have an account that can log into several things. The only thing I am saying here is I have 2 users depending on the access I want to give, which again isn't unheard of, and even AWS recommends that your Admin account is separate from user accounts. To your point typically you would just have a user a and then if you needed more permissions you could make an elevation request. Which in itself has its own risks and downfalls. Which bring it back full circle. even looking at 1 user if the profile I log in with is connected to a user that has admin role and normal role. I personally expect that if I have 2 different roles I would have 2 different tokens/secrets. If nothing more to give me the façade that they are a bit separate. I just have a problem with the fact that 2 roles with potentially highly different permissions are using the same base token/secret to generate from. Instead of 2 different tokens/secrets to ensure that they do not cross streams. |
|
There are separate cache entries for every profile, in You can only be logged in through |
|
Can you tell me if the browsers-side experience for AWS SSO, with the AWS web console, matches your expectations, or do you have similar feelings about it? |
|
When I use the browser I only have access to what the user has access and I am presuming the token is based as such. It regens based on the user that logs in. Which is 100% what I expect. But with AWS you can only be in 1 user in 1 account. at a time. To your point there are some extras that the cli is doing. |
|
You can argue that it requires access to the computer and then someone has larger issues. But still shouldn't some things try to mitigate that risk. The goal of things is to make scripts that can do the work for you. I shouldn't have to worry that I created a script to use boto so I can touch multiple accounts easily instead of cli, since with cli if I have 100 accounts I would have to have a profile for each account. With boto, I can use the profile cache and generate creds to touch any account I Want. |
|
I'm confused; there isn't a difference between the access or scripting you could do with boto3 vs the CLI. The AWS SSO API explictly allows enumeration of the access a user has; this is what powers the autocompletion of If your complaint is that you'd like the ability to have the AWS SSO token when you're logging in have smaller scope, that's a completely valid request, and is supported in theory by the authentication API, which allows the specification of None of that changes that the cache key for the SSO token cache would be the start URL, because there should only be one of these tokens at a time. And I think you in particular actually want that, because it would mean you couldn't use two different profiles that you expect to use with two different identities at the same time. |
|
It's also a valid complaint that the implied scope of |
|
If you wanted to list all ec2 instances across 10 accounts and you were using SSO the following fails So you would need 2 different profiles |
|
I have created my own util that allows me to read the sso cached data and create tokens/secrets per account based on a role I Want to make. It is easy for someone to pass in admin and just get full access since the main sso token/secret is not scoped to be limited. |
|
@benkehoe |
|
For the CLI, I can create a bash script that uses I do agree it's easier in Python, and I too wrote utilities for it 🙂, available on PyPI as
I think this is the crux of your issue, and as I said, it's a completely valid complaint that I agree with, but is not solved by modifying the AWS CLI's cache design for SSO tokens, only by changing the SSO authentication API to be able to return tokens with smaller scopes. |
|
Yup, your util is what got me started, I figured there had to be a simpler way Which then lead me down a horrible rabbit hole. Fix the SSO Authentication API so it can return smaller scopes, and to separate out the sso cache tokens. |
|
I'm not clear about how cache full of small-scoped tokens is substantially better than a cache with one token with all the same access. You mentioned the browser only being able to be one role at a time as a positive thing, wouldn't it be a positive thing for the CLI only to be logged in as one scoped access at a time? That is, if you went from being logged in as Normal to be logged in as Admin, you'd have to re-login as Normal to use it again? |
|
I like how the browser feels like it has that limited scope, but that is only a facade because it only lets you be in 1 account, with 1 role at a time. The difference is each SSO profile is now scoped to the limit the permissions at the main token/secret level. So if I have 2 profiles one with normal access and one with admin access. No one can use the normal one to get admin access. I can invalidate the admin one without invalidating the normal one. So if I have a script that calls other scripts. 10 of the other scripts all run as normal, but 1 script needs admin that 1 that needs admin can still get it without breaking the session on the others and I know the others still have a hard scope. If I tried to do something mailouts with a master token/secret that was scoped to a normal role I couldn't. It could also mean that as a developer you could set a normal login cache for longer than an admin one. My admin Token I would want to expire after 30 minutes, but the normal one is ok that its once a day. Again, it leads to its own wormhole. But it starts with being able to limit the scope at the main token/secret level. Where should the requirement to ensure my access is limited be enforced. With the separate I can have my script auto log out of the admin but leave the normal alone and continue my daily activities without missing a beat. Which should I have to log back into normal I didn't elevate it I used a different profile and different scope. |
|
I see where you're coming from, but it seems like a weird place to put those constraints, given the upstream browser cookies still have the broad access. There's still no re-authentication with you, the human, required to get the Admin-scoped token back. So AWS SSO should have rules about re-authentication for given scopes. Even then, I'd say I'd want more like "get a new elevated token that includes the Admin scope" followed by "get a new token that excludes the Admin scope", rather than manage multiple tokens. But we can come back to that debate once the API has the feature we want 😄. |
|
@benkehoe I am good with that. I would say that some of this could apply at the upstream browser level. But again, an interesting conversation once the API is updated |
|
Thanks @benkehoe for your superb engagement here! I appreciate the callout of what 'user', profile, and 'human currently using the computer' mean here to help clarify. @tikicoder, given all of this discussion I hope you're in a place that you understand what the AWS CLI and the Python SDK allows you to do with SSO and why. There are some improvements to the documentation that I can take away from here, marking this one as such. With respect to feature changes, is there still anything other the scope of tokens (which isn't for Python SDK directly to solve), or the user experience with how you login (covered by aws/aws-cli#5727, I think)? |
|
@kdaily I think there is still a conversation about also the whole multi profile with the same starturl. Again if I am running 2 users even if the roles are the same I should be able to track them separately or as you go from one profile to the next does that log you out of the other profile. To me I have 2 profiles regardless and I should be able to ensured they are tracked/treated separate. I will stand firm on that, but again I understand if people disagree. I mean if I was living in an apartment and I had roommates they shouldn't be able to call up my cell provider and be treated as me just because we live under the same roof. I understand everything, so I get why, but I can disagree. But again the scope is a win. |
joguSD
changed the title
|
We've definitely seen a lot of confusion around how an That being said, having this configuration alongside the For example something similar to @benkehoe's suggestion in aws/aws-cli#5727: Would make it clear that |
|
This would become very relevant if AWS SSO starts supporting scopes and custom expirations for the token. I could imagine a config file like [sso-session admin]
start_url = https://example.awsapps.com/start
region = us-east-2
scope = admin
duration = 1 hour
[sso-session dev]
start_url = https://example.awsapps.com/start
region = us-east-2
scope = not-admin
duration = 8 hours
[profile admin-A]
sso_session = admin
sso_account_id = 111122223333 # admin in account A
sso_role_name = Administrator
[profile admin-B]
sso_session = admin
sso_account_id = 222233334444
sso_role_name = Administrator
[profile dev-A]
sso_session = dev
sso_account_id = 111122223333
sso_role_name = Developer
[profile dev-B]
sso_session = dev
sso_account_id = 222233334444
sso_role_name = Developer |
|
Thank you for getting me in this rabbit hole. 😄 I noticed that the sso cache expiresAt value is not updated for a while when I run But reading this thread made me understand better how the SSO works. |
Describe the bug
The logic around how you name the cache files is flawed.
The way the cache File name is determined is based on the SSO Start URL. What happens when you have multiple profiles with the same start_url
Steps to reproduce
View the following links,
botocore/botocore/utils.py
Line 2368 in b006ff7
https://github.com/aws/aws-sdk-go/blob/b9d2b59a417d8332de5d8a598976dc27416a4443/aws/credentials/ssocreds/provider.go#L117
https://github.com/aws/aws-sdk-go-v2/blob/b7d8e15425d2f86a0596e8d7db2e33bf382a21dd/credentials/ssocreds/provider.go#L103
Expected behavior
The cache file name should be based on the profile name or profilename + url
Debug logs
This could cause the the system to use the wrong creds.
The text was updated successfully, but these errors were encountered: