Use the right credentials when using SSM features

Make sure we're using the right set of credentials when doing SSM target resolution, so the API calls are using the roles in the correct accounts when using jump roles.

Validate SAML parameters before doing AssumeRoleWithSAML

Check that we have something resembling a value in the SAMLAssertion and PrincipalARN before making the AssumeRole call. We'll leave the data validation to AWS, but make sure we provide a more helpful error message in case these values aren't set.

Validate SAML parameters before doing AssumeRoleWithSAML

Check that we have something resembling a value in the SAMLAssertion and PrincipalARN before making the AssumeRole call. We'll leave the data validation to AWS, but make sure we provide a more helpful error message in case these values aren't set.

Allow private IP address and tags for SSM targets

EC2 instance private IPv4 addresses and instance tags can now be used to specify a target instance when using runas for SSM sessions and port forwarding. This is in addition to providing the instance ID directly, and using DNS TXT records.

Support DNS names when using SSM session and port forwarding

In addition to standard EC2 instance identifiers, DNS names can be used as SSM targets. If a DNS name is detected, a TXT DNS record lookup will be performed, and the first entry which looks like an EC2 instance ID will be returned.

EC2 metadata service fixes

Correct some behaviors when using the EC2 metadata service feature with SAML profiles

• Periodically refresh the SAML assertion from the IdP as AWS rejects any assertion data older then 5 minutes.
• If using a "jump role" with SAML, cache the credentials from the AssumeRoleWithSaml call to avoid extra communication with the IdP
• Add back the ability for the metadata service to get credentials for the profile specified on the command line during startup. This allows simple uses of a single profile to avoid having to make a trip to the web UI in order to set the profile.

2.1.0

Add support for using Okta as a SAML provider, only supports token and push MFA, at this time

Update OneLogin SAML client so that it persists a user's login state so user's aren't required to re-auth each
time they run aws-runas. This will require a change to the saml_auth_url for OneLogin clients. The new
general form of the URL is:

https://my-tenant.onelogin.com/trust/saml2/launch/__app-id__

where the app-id value can be found on the user's application landing page, hovering over the OneLogin AWS Application, and getting the last element in the URL path.

When using the --verbose flag, decode the SAMLResponse and provide the interesting bits related to the AWS AssumeRole operations. This way users don't have to manually deal with handling the SAMLResponse.

2.0.5

Fix Forgerock error message checking with MFA which was causing erroneous Authentication Failure messages when authenticating against the IDP.

(The username/password authentication succeeded, but it was mis-handling the error message which was returned from the server.)

2.0.4

Add hidden field info during Keycloak login

Additionally add extra logging to the authentication failure error to help narrow down where issues happen.

2.0.3

clean out dead code paths in the keycloak SAML client

Unnecessary URL parsing was causing errors for some users. Since
the parsed bits aren't even used by the client, they should be
disabled.