From within Okta, a user is assigned to only one SAML User Role. This results in no selections being present yet the prompt to make a selection is still presented.

Looking at the code it appears to parse the AWL SAML role selection page to determine what to present in that selection. As the user is only assigned to one SAML User Role this selection page isn't presented and the user is dropped right into the Identity account.

I just got this tool working, thanks for putting this up here. I was using a Python based tool we wrote internally that was using requests, but doesn't work now that the login page is JavaScript enabled. I think the ability to pass in command line arguments, such as profile save name, IdP app url, region, output format (for the credentials file) would be awesome. Just wanted to pass that on.

Great work!

After running './awscli sts get-caller-identity' and entering username and password, i then receive the following:

Exception in thread "main" java.net.UnknownHostException: https: nodename nor servname provided, or not known
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:924)
at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1504)
at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:843)
at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1494)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1353)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1287)
at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:111)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at com.okta.tools.OktaAwsCliAssumeRole.logInToOkta(OktaAwsCliAssumeRole.java:205)
at com.okta.tools.OktaAwsCliAssumeRole.getAuthnResponse(OktaAwsCliAssumeRole.java:142)
at com.okta.tools.OktaAwsCliAssumeRole.getOktaSessionToken(OktaAwsCliAssumeRole.java:125)
at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:86)
at com.okta.tools.awscli.main(awscli.java:27)

Hello, I've followed the instructions in the readme, but I'm not able to log in.

⇒  ./awscli.command
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: com/amazonaws/auth/AWSCredentials
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: com.amazonaws.auth.AWSCredentials
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 7 more

When executing the awscli with the following properties:
OKTA_ORG=[okta tenant]
OKTA_AWS_APP_URL=[application url]
OKTA_USERNAME=
OKTA_PASSWORD=
OKTA_AWS_ROLE_TO_ASSUME=

I am prompted to authenticate as expected. When I execute the awscli a second time I get the following Exception:
Exception in thread "main" java.lang.NullPointerException
at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:109
)
at com.okta.tools.awscli.main(awscli.java:31)

At this point. From the code there is a check for oktaProfile.isEmpty()
if (session.isPresent() && sessionIsActive(startInstant, session.get()) && oktaProfile.isEmpty())

Since this property is not defined a NullPointerException is thrown. When I add the property to the config.properties. The exception goes away and everything works as expected. Except for logout.

Logout throws the following exception:
Exception in thread "main" java.lang.NullPointerException
at org.ini4j.BasicProfile.remove(BasicProfile.java:139)
at com.okta.tools.aws.settings.MultipleProfile.deleteProfile(MultipleProfile.java:47)
at com.okta.tools.OktaAwsCliAssumeRole.logoutMulti(OktaAwsCliAssumeRole.java:158)
at com.okta.tools.OktaAwsCliAssumeRole.logoutSession(OktaAwsCliAssumeRole.java:144)
at com.okta.tools.awscli.main(awscli.java:25)

If I remove the property from the config then logout works, so I am in a catch 22 scenario.

For federated cross-account cases, we can now get sessions longer than 1 hour in the web console (as of 2016.46/47), but this tool is still only handing out 1-hour sessions. It should inherit the setting of the app instance.

We use application level sign on policies to enforce MFA for specific applications, however the cli tool doesn't support this. I saw an closed issue from August due to lack of API support. Has this been added to the API? Is there some other solution to this problem?

Hi guys,

Is there any way to allow user to pick the region that is populated in the config file?

if not anyway we can get it added to the config.properties ?

Thanks

Wondering if there's a timeline in adding the ability to extend the token to 12 hours per the new functionality in AWS?

Hi,

I was using an older version quite some time ago with success, I was able to run ./awscli, get prompted for username and password, choose my okta role and then the AWS role policy I wanted to assume. From there I was able to use the profile as expected (primary use is with Terraform) and assume roles in other accounts.

Since that version it looks like quite a bit has changed.

Now when running awscli, I no longer get prompted to assume a role policy, and when I run ./awscli sts get-caller-identity a second time, I get:

Exception in thread "main" java.lang.NullPointerException
        at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:109)
        at com.okta.tools.awscli.main(awscli.java:31)

Is there something I'm missing? I was getting the not authorized to perform: sts:AssumeRole on resource but fixed that with the suggested inline policy.

Hello, I wanted to ask if this tool supports Spoke/Hub model?

When pointing OKTA_AWS_APP_URL, OKTA_ORG to the HUB, it works.When changing this variables to the Spoke I get:
16:55:28.957 [main] ERROR com.okta.tools.awscli - You do not have access to AWS through Okta. Please contact your administrator.

AWS Application nevertheless is working on fine in the Browser.

Best regards,
Joaquín

This worked great for me when Okta MFA was turned off in my organization. Since we enabled it, this process seems to fail, giving me the message: You do not have access to AWS through Okta. None of my AWS settings have changed.

At first glance, the Document received from the launchOktaAwsApp method is a redirect page and does not contain the SAML token in the form expected to use to call AWS. Things work fine if I disable MFA, but that is not a acceptable workaround.

The directions in https://github.com/oktadeveloper/okta-aws-cli-assume-role#configuring-the-application do not work. This only seems to work if config.properties is in the CWD when you execute the script.

I believe #14 fixes this.

Hi, any idea when we can expect it?

https://github.com/oktadeveloper/okta-aws-cli-assume-role/blob/4aae908451bef7dac8a9d9ac2a8496339fa3a4df/src/main/java/com/okta/tools/awscli.java#L458

Without it we have to one-to-one map policies to roles.

Recently #48 was merged. These changes make sure default profiles will not be overwritten.
However, I was wondering what we should do when there aren't any $HOME/.aws/config and $HOME/.aws/credentials configuration files yet.

Maybe we should write the newly created profile as a default profile in case there is no previous aws-cli credentials configuration, and add/update it if there is.
That way people that use only this tool to set up aws-cli configuration will have a usable default profile, and people that had already setup aws-cli configuration will have their default profile kept intact.

The current version will just write an empty (unusable) default profile in addition to the newly generated profile if there is no previous aws-cli config.

What is the license for this project? Could you please update the repository with the license file?
Thank you.

From the AWS docs:

The default AWS Security Token Service (STS) endpoint ("sts.amazonaws.com") works for all accounts that are not for China (Beijing) region or GovCloud. You only need to change the endpoint to "sts.cn-north-1.amazonaws.com.cn" when you are requesting session credentials for services in China(Beijing) region or "sts.us-gov-west-1.amazonaws.com" for GovCloud.

source

A quick fix, I think, would be to add the (deprecated) withServiceEndpoint builder to the code below:

https://github.com/oktadeveloper/okta-aws-cli-assume-role/blob/4dbfb4a7d7ddfb85e5567781d55e3736421c9282/src/main/java/com/okta/tools/awscli.java#L419-L423

Longer term, we should move the code to use to the AWSSecurityTokenServiceClientBuilder

Hi,

I have an issue when trying to run this on a Windows 7 box, here is the error I'm getting:

\java -classpath oktaawscli.jar:../lib/aws-java-sdk-1.11.27.jar com.okta.tools.awscli
Error: Could not find or load main class com.okta.tools.awscli

I have a feeling it's a syntax error but not sure, help would be appreciated.

There are a number of outstanding/closed PRs and issues around artifact building. Is there any interest from the maintainers on integrating this? If there is, I would be happy to try to shepherd those changes into a single PR with the help from the original submitters.

Related:

• #19
• #31
• #27
• #12
• #9

Hello @AlainODea! Can you please tell me what needs to change in https://support.okta.com/help/Documentation/Knowledge_Article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta so it's up-to-date with this repo?

@mraible I think your suggestion publishing to Maven Central from Travis is a practical solution to this problem.

@loopingz do you agree? S3 is an option, but I think Maven would be easier to discover and consume.

I believe that the aws sdk and powershell module put their configuration in %home%.aws. This tool uses the java variable user.home, which returns the windows variable for %userprofile%.

I'm no java developer otherwise I would figure out how to get this working and submit the code changes my self.

Thanks for putting up nice tool and I got it working. I have multiple roles but if I want to select to one role and then I want to select another role before my orginal okta session expires, right now if I do this (before expiring old session) ./awscli sts get-caller-identity, it shows me details for old session rather than prompting a new session.

Please let me know if I'm missing something.

Thanks

I am using this tool to assume a role in the same organisation as the user I use to access was via okta, when I run the tool I get an error.

My config looks like:

OKTA_ORG=domain.oktapreview.com
OKTA_AWS_APP_URL=https://domain.oktapreview.com/home/amazon_aws/0ia84r1fghTqB61ZR9h7/137
AWS_IAM_KEY=MYKEY
AWS_IAM_SECRET=MYSECRET

When I run the tool I get:

Username: my_okta_name
Password: my_okta_password

Please choose the role you would like to assume: 
[ 1 ]: arn:aws:iam::124546611879:role/Role_I_want_to_assume_in_same_org
Selection: 1
Exception in thread "main" com.amazonaws.services.identitymanagement.model.AmazonIdentityManagementException: The security token included in the request is invalid. (Service: AmazonIdentityManagement; Status Code: 403; Error Code: InvalidClientTokenId; Request ID: 140d6651-c6a3-11e6-973b-81205f56c3d6)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1545)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1183)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:964)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:676)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:650)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:633)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:601)
	at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:583)
	at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:447)
	at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.doInvoke(AmazonIdentityManagementClient.java:6882)
	at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.invoke(AmazonIdentityManagementClient.java:6858)
	at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.getRole(AmazonIdentityManagementClient.java:3670)
	at com.okta.tools.awscli.GetRoleToAssume(awscli.java:435)
	at com.okta.tools.awscli.main(awscli.java:119)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)

If I comment out line #119 GetRoleToAssume(crossAccountRoleName); in awscli.java, then the tool works correctly and generates temporary credentials that allow the aws cli to connect.

The issue seems to be that variable crossAccountRoleName gets set to the role name [1] selected above, which results in an attempt to assume a cross account role that does not exist, as this role is in the same organisation as the user.

Is there some additional config I can define to prevent the attempt to assume a cross account role?

The article published here seems to indicate that MFA works but that doesn't seem to be the case in my testing. I get this result every time I try to use it with MFA required in my sign on policy:

You do not have access to AWS through Okta. Please contact your administrator.

When I test access through the browser I get prompted for MFA and it works as expected.

$ ./awscli
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: too few arguments
$

config.properties contains OKTA_ORG and OKTA_AWS_APP_URL. I was prompted once for credentials but removed the credential file to test something. Ever since then I haven't been prompted for auth on run of the jar, and ~/.aws/credentials is not repopulated. Repo cloned and built Feb 2, approximately 11:30 AM CST. Don't know if there's a 'stable' branch I should be cloning instead or if there's a known defect.

Is anyone maintaining this actively atm?

Doing nothing (running true, a trivial program that exits with code 0) with this is now surprisingly slow, suggesting that there is a major performance regression somewhere:

$ time true

real	0m0.000s
user	0m0.000s
sys	0m0.000s
$ time env OKTA_PROFILE=dev ./withokta true

real	0m4.252s
user	0m7.162s
sys	0m0.355s

Using the oktaawscli.jar from 8af9de9, I get this dramatically faster experience:

$ time env OKTA_PROFILE=dev ./withokta true

real	0m0.884s
user	0m1.825s
sys	0m0.153s

The regression was introduced by #83, so I suspect it has something to do with refreshing the Okta session. It looks like refreshing the session costs over 3 seconds, which adds up to a huge cost if withokta is used to wrap every line in a script.

I think a different strategy for session refresh (possibly paying the session refresh price once every 5 minutes, or doing it in a second background task) might be worthwhile.

@smashling we'll take a look at this some time soon, but #88 is definitely a bigger immediate issue.

When executing the prebuilt Jar, it throws a NoClassDefFoundError: com/amazonaws/AmazonClientException error.

Executing the code in IntelliJ does not produce the same output, rather, it works as intended.

This is due to a dependency reference missing that points at the lib folder in the iml file.

First off, thanks for this great tool. It greatly simplifies the AWS STS interaction.

Our company uses an explicit proxy to access the Internet. I can't find a way to have this program use the proxy, and thus it simply fails when running on our internal network.

I've tried setting the proxy in the traditional way via environment variables, as well as via the traditional JAVA way with -Dhttps.proxyHost directives and neither approach seems to work.

export http_proxy="http://usrname:passwrd@host:port"

java -Dhttps.proxyHost=proxy.global.dish.com -Dhttps.proxyPort=8080 -Dhttps.proxyUser=firstname.lastname -Dhttps.proxyPassword=Dish1234! -classpath .:oktaawscli.jar:../lib/aws-java-sdk-1.11.37.jar com.okta.tools.awscli

Is Proxy Support built-in and I'm just missing it? If it's not built-in, what are the chances it could be incorporated?

@alamir1 I'm moving this conversation to a new issue.

Symantec VIP has a distinct factorType that I didn't account for. The same thing happened to Yubikey support, but I had a user who I could test with and who works in a desk beside me so I was particularly motivated 😁

https://github.com/oktadeveloper/okta-aws-cli-assume-role/blob/master/src/main/java/com/okta/tools/OktaAwsCliAssumeRole.java#L476-L477

I think this an easy fix:
https://developer.okta.com/docs/api/resources/factors#supported-factors-for-providers

I think I can add token as another fallthru case and Symantec VIP should work again:

                case ("token):
                case ("token:hardware"):
                case ("token:software:totp"): {

Great tool, little clunky to setup but it works and it's really smooth once you get there.

I am getting an issue, though it's actually working so I'm a bit confused.

Environment:

• Windows 10 Anniversary Edition
• aws-java-sdk-1.11.37
• downloaded the zip file from here last week
• run either in a standard powershell or cmd.exe shell i receive the same error/experience
• followed this article for setup/configuration: https://support.okta.com/help/articles/Knowledge_Article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta?retURL=%2Fhelp%2Fapex%2FKnowledgeArticleJson%3Fc%3DOkta_Documentation%253ATechnical_Documentation%26p%3D101%26inline%3D1&popup=true

This output has been scrubbed a little for security

[3|2:04 PM|+1ms] [...\okta-aws-cli\out]
> .\awscli.bat

C:\users\jbruett\Documents\okta-aws-cli\out>java -classpath oktaawscli.jar;../lib/aws-java-sdk-1.11.37.jar com.okta.tool
s.awscli
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.
Username: <username>
Password: <password>

Please choose the role you would like to assume:
[ 1 ]: arn:aws:iam::###########:role/<role1>
[ 2 ]: arn:aws:iam::###########:role/<role2>
Selection: 1
Exception in thread "main" java.lang.NullPointerException
        at com.okta.tools.awscli.GetRoleToAssume(awscli.java:493)
        at com.okta.tools.awscli.main(awscli.java:133)

regardless of the error, i have a valid session and the credentials are successfully written to file. I'm thinking that this is something to do with the ERROR about log4j2, but it's there, so i'm not sure

The following line in Readme.MD is macOS specific. It should probably note that, and if there is an equivalent command for Windows, that should probably be added.

In Terminal, run defaults write com.apple.finder AppleShowAllFiles YES if you want to be able to inspect the ~/.aws/credentials and ~/.aws/config files.

I have an iam role that looks like:

arn:aws:iam::XXXXXXX:role/aplp/Role-IT-PlatformTeam

Noticed i used "aplp" as a "folder" to store all our roles moving forward. The issue I'm having is the cli seems to not like the fact that it sees it as aplp/Role-IT-PlatformTeam now, that by design or???

http://i.imgur.com/jIJNnti.png

We ran into an issue where one of our developers had [default] profile credentials already setup in the aws credentials file. Nowhere in your documentation did we see that these would be overwritten.

I'm moving to Duo from SMS for MFA, but I'm blocked on lack of Duo support in the cli. What is preventing support for Duo? I'm happy to contribute if it just takes some programming effort. Alternatively, can you offer a workaround for AWS CLI/API access when using Duo?

After being prompted for your MFA code, so far having tested both SMS and Google Authenticator, you'll be greeted with an error. Here's a stacktrace:

./awscli.command
Username: <my username>
Password: <my password>

Multi-Factor authentication is required. Please select a factor to use.
Factors:
[ 1 ] : Google Authenticator

GOOGLE Token Factor Authentication
Enter 'change factor' to use a different factor
Token:
xxxxxx
Exception in thread "main" java.lang.RuntimeException: You do not have access to AWS through Okta.
Please contact your administrator.
	at com.okta.tools.OktaAwsCliAssumeRole.getSamlResponseForAws(OktaAwsCliAssumeRole.java:358)
	at com.okta.tools.OktaAwsCliAssumeRole.getSamlResponse(OktaAwsCliAssumeRole.java:125)
	at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:111)
	at com.okta.tools.awscli.main(awscli.java:31)

Having checked this across multiple users, and accounts, and verifying we do indeed have access to AWS through Okta - my conclusion has to be that this is a bug or regression.

Here are some related issues in the past with similar problems:
#2
#61

Currently the tool supports only one linked account and doesn't get token when multiple accounts are linked:

14:30:12 [main] DEBUG com.okta.tools.awscli - Statement node: {"Effect":"Allow","Action":"sts:AssumeRole","Resource":["arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>","arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>","arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>"]}
14:30:12 [main] DEBUG com.okta.tools.awscli - Statement is NOT array
14:30:12 [main] DEBUG com.okta.tools.awscli - Resource node: ["arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>","arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>","arn:aws:iam::<REDACTED_ACCOUNT_ID>:role/<REDACTED_ROLE>"]
14:30:12 [main] DEBUG com.okta.tools.awscli - Role to assume: null
14:30:12 [main] TRACE com.okta.tools.awscli - Role to assume ARN: null

After installing the aws cli through python, I attempt to run awscli.bat, and get the following error:

Exception in thread "main" java.io.IOException: Cannot run program "aws": CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessBuilder.start(Unknown Source)
        at com.okta.tools.awscli.main(awscli.java:36)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(Unknown Source)
        at java.lang.ProcessImpl.start(Unknown Source)
        ... 2 more

My initial guess was an issue with the way my PATH variable was setup, but running aws from the command line resolves correctly, and it also looks like the correct directory C:\Program Files\Python36\Scripts has been added to the PATH.

Can you all identify anything that I may have missed in order to execute this command correctly?

Below is execution of aws from Powershell with Admin access. The same result also occurs from my user-level account.

PS C:\> aws
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: the following arguments are required: command

This is a snapshot of my system-level environment variables. I have included the Python paths in both User and System.

Why is the timeout hardcoded? Can this be parameterised? If the Okta Application sets a timeout of 8 hours, the CLI tool should respect that.

https://github.com/oktadeveloper/okta-aws-cli-assume-role/blob/b8ce7d17fe383fb9c420eb0e0fe7d9a82ea8778e/src/main/java/com/okta/tools/awscli.java#L428

Okta implemented new method to console login to child accounts. This new method uses a fixed role: Okta-Idp-cross-account-role

I don;t believe the cli takes this into account. AWS credentials being used is from account 2222222222 which works because the cli uses the GetRole command. But fails when selecting 1234567890, possibly because it is running the GetRole command but the role is not in 2222222222 account and is not switching roles to the 1234567890 account via Okta-Idp-cross-account-role before doing the GetRole
sdk-1.11.165.jar com.okta.tools.awscli
Username: myuser
Password:

Please choose the role you would like to assume:
[ 1 ]: arn:aws:iam::1234567890:role/Testing1
[ 2 ]: arn:aws:iam::2222222222:role/Testing2
Selection: 1
13:46:27 [main] DEBUG com.okta.tools.awscli - Cross-account role is Testing1
13:46:28 [main] DEBUG com.okta.tools.awscli - Creating the AWS Identity Management client
13:46:28 [main] DEBUG com.okta.tools.awscli - Getting role: Testing1
Exception in thread "main" com.amazonaws.services.identitymanagement.model.NoSuchEntityException: Role not found for Testing1 (Service: AmazonIdentityManagement; Status Code: 404; Error Code: NoSuchEntity; Request ID: 052303fa-7098-11e7-9234-1707482cd147)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1587)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1257)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1029)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:741)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:715)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:697)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:665)
at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:647)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:511)
at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.doInvoke(AmazonIdentityManagementClient.java:8275)
at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.invoke(AmazonIdentityManagementClient.java:8251)
at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.executeGetRole(AmazonIdentityManagementClient.java:4390)
at com.amazonaws.services.identitymanagement.AmazonIdentityManagementClient.getRole(AmazonIdentityManagementClient.java:4367)
at com.okta.tools.awscli.GetRoleToAssume(awscli.java:437)
at com.okta.tools.awscli.main(awscli.java:119)

This was talked about in the recent AWS CLI talk at re:Invent

By supporting returning a specific JSON object, as described here: http://docs.aws.amazon.com/cli/latest/topic/config-vars.html#sourcing-credentials-from-external-processes okta-aws-cli-assume-role can integrate better with the aws-cli command.

See example here: https://github.com/awslabs/awsprocesscreds

/cc: @AlainODea @mraible @rdegges @joelfranusic-okta

I am using MacBook Pro 10.12.6 and not being able to set up the cli correctly.
Here is the step by step setup.

1. Install JDK from http://www.oracle.com/technetwork/java/javase/downloads/index.html

% java --version                                                                                    
java 9.0.4
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

2. % brew install maven
3. % git clone https://github.com/oktadeveloper/okta-aws-cli-assume-role.git
4. % vim config.properties (Edit OKTA_ORG and OKTA_AWS_APP_URL)
5. % mv config.properties out
6. % mvn package
7. % cp target/okta-aws-cli-1.0-SNAPSHOT.jar out/oktaawscli.jar
8. % cd out

Now, I executed ./awscli sts get-caller-identity and it gives me following error.

[ksuzuki@A-M-201711-003] ~/workspace/okta-aws-cli-assume-role/out
% ./awscli sts get-caller-identity                                                                              (git)-[master]
Username: ksuzuki (or [email protected])
Password:
Exception in thread "main" java.net.UnknownHostException: https: nodename nor servname provided, or not known
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:924)
	at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1504)
	at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:843)
	at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1494)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1353)
	at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1287)
	at org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:111)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
	at com.okta.tools.OktaAwsCliAssumeRole.logInToOkta(OktaAwsCliAssumeRole.java:224)
	at com.okta.tools.OktaAwsCliAssumeRole.getAuthnResponse(OktaAwsCliAssumeRole.java:161)
	at com.okta.tools.OktaAwsCliAssumeRole.getOktaSessionToken(OktaAwsCliAssumeRole.java:144)
	at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:99)
	at com.okta.tools.awscli.main(awscli.java:29)
[ksuzuki@A-M-201711-003]

I am not sure what I am missing at this point. Any suggestion will be helpful.

Right now when selecting a role to assume, we are shown account numbers instead of the account name/alias if it exists. Since most of our users won't recognize the account number immediately, this means we have to make which account each role is part of clear in the role name itself. Wouldbe nice to have the account names listed instead so we could avoid that.

first run works fine. But, if I run the commands again to get keys for a different role it fails unless I remove the session file ~/.okta-aws-cli-session
./awscli sts get-caller-identity
Exception in thread "main" java.lang.NullPointerException
at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:109)
at com.okta.tools.awscli.main(awscli.java:31)

I have a use case where I have two AWS accounts, one for prod and one for non-prod.
Both accounts are configured to talk to Okta.How can i use two Embed links in the config file to get temporary credentials from both the AWS accounts?

The program is currently not really install-able.

Attempts to move it and its script into a bin directory on the PATH don't work as it needs config.properties in the current working directory.

Accepting properties from ~/.okta/config.properties is one step in that direction. The Gradle application plugin is another option.

Either way, it would be useful for this to be install-able so it can be rolled out to a large team efficiently.

@smashling can you look into this?

It's possible to configure session duration in the UI and should be also possible to configure it using CLI tool. Can be done by parametrising this line.

Has support for cross-account roles, implemented in this pr been removed?

The app doesn't present a choice of roles that the main role can switch to and assumes main account role automatically.