Aws-toolkit-jetbrains: using source_profile to point to an SSO based profile is broken

[flyinprogrammer]

Describe the bug
In theory you can use a source_profile credentials to automagically create credentials for a specified role_arn. This seems to be broken in our our SSO implementation because our validator seems to think our assume role profile needs all the fields the source profile has - which is bananas - but also understandable because this stuff is hard.

To reproduce

Create an ~/.aws/config that looks like this:

[profile dev]
sso_start_url=https://<secret>.awsapps.com/start/
sso_region=us-east-2
sso_account_id=<secret>
sso_role_name=AWSPowerUserAccess
region=us-west-2
output=json
credential_process=/usr/local/bin/aws-vault exec dev --json

[profile atlantis]
source_profile = dev
role_arn = arn:aws:iam::<secret>:role/atlantis

Open intellij, view the stacktrace :smile:

Expected behavior

AWS Toolkit would use the dev profile to assume the role specified in the atlantis profile, when we tell AWS Toolkit to use the atlantis profile.

Screenshots

java.lang.IllegalArgumentException: Profile 'atlantis' is missing required property sso_start_url
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileUtilsKt$requiredProperty$2.get(ProfileUtils.kt:43)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileUtilsKt$requiredProperty$2.get(ProfileUtils.kt)
    at java.base/java.util.Optional.orElseThrow(Optional.java:408)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileUtilsKt.requiredProperty(ProfileUtils.kt:42)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileCredentialProviderFactory.asId(ProfileCredentialProviderFactory.kt:331)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileCredentialProviderFactory.loadProfiles(ProfileCredentialProviderFactory.kt:107)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileCredentialProviderFactory.access$loadProfiles(ProfileCredentialProviderFactory.kt:75)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileCredentialProviderFactory$setUp$1.invoke(ProfileCredentialProviderFactory.kt:85)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.ProfileCredentialProviderFactory$setUp$1.invoke(ProfileCredentialProviderFactory.kt:75)
    at software.aws.toolkits.jetbrains.core.credentials.profiles.DefaultProfileWatcher$prepareChange$3$afterVfsChange$1.run(ProfileWatcher.kt:73)
    at com.intellij.util.RunnableCallable.call(RunnableCallable.java:20)
    at com.intellij.util.RunnableCallable.call(RunnableCallable.java:11)
    at com.intellij.openapi.application.impl.ApplicationImpl$1.call(ApplicationImpl.java:268)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
    at java.base/java.lang.Thread.run(Thread.java:834)

Your Environment

• OS: Pop OS 20.04
• JetBrains product: Intellij Ultimate Edition
• JetBrains product version: 2020.2.3 Build #IU-202.7660.26
• AWS Toolkit version: 1.19-202

Additional context
This works for other tools like aws-vault, so I imagine y'all can get this to work, and this is simply a regression of sorts.

[abrooksv]

Alan?! Small world...

We wanted to show that the user needs to interact with SSO instead of immediately triggering it on IDE opening which makes sense...but its grabbing the SSO details from the top level profile (atlantis) instead of further down the profile chain (dev).

I traversed the profile chain looking for SSO, but then I just grabbed the SSO details from the top of the chain.

[flyinprogrammer]

I traversed the profile chain looking for SSO, but then I just grabbed the SSO details from the top of the chain.

No problem at all - this stuff is hard! Your comment led me to discover all the hard work y'all did to make logging into SSO easy to do - and that y'all are using the cached oidc session to create profiles that share the same sso_start_url - which is great because a lot of tools get this all wrong. Keep up the awesome work!

[abrooksv]

Fix has been released in 1.20

[flyinprogrammer]

Can confirm, it works!