This change adds support Okta Identity Engine domains. Since OIE has much more complicated login policies and has dropped support for the sessionToken parameter when requesting a SAML response, we have to use the device authorization flow and request a Web SSO token to exchange for the SAML response. This login flow mirrors the one used by okta-aws-cli. The main difference from okta-aws-cli's implementation is that I stuck with using the OKTA_API_KEY environment variable instead of using the okta.apps.read scope to access the Apps API. The client calls a metadata endpoint on the target Okta domain and determines if it is a classic or OIE domain and selects the correct login flow, so no changes to the config file are needed.
In addition, I also added an expiration time (x_security_token_expires) to the AWS credentials file to match the existing feature in saml2aws.
Finally, I updated the tests to use pytest since nose does not support Python 3.10+ and dropped support for Python 3.6 since there were incompatibilities with some of the libraries we use.
Please note: This change does not support non-interactive logins, which not currently possible with OIE. Once Okta has a solution for non-interactive logins, support for that will be added.
Related Issue
345
365
329
Motivation and Context
OIE support in gimme-aws-creds is a requirement before we can migrate to OIE.
How Has This Been Tested?
Tested against an OIE and classic domains. All existing functionality on the classic domain is still working.
Screenshots (if appropriate):
N/A
Types of changes
[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[X] My code follows the code style of this project.
[X] My change requires a change to the documentation.
Description
This change adds support Okta Identity Engine domains. Since OIE has much more complicated login policies and has dropped support for the
sessionTokenparameter when requesting a SAML response, we have to use the device authorization flow and request a Web SSO token to exchange for the SAML response. This login flow mirrors the one used by okta-aws-cli. The main difference from okta-aws-cli's implementation is that I stuck with using theOKTA_API_KEYenvironment variable instead of using theokta.apps.readscope to access the Apps API. The client calls a metadata endpoint on the target Okta domain and determines if it is a classic or OIE domain and selects the correct login flow, so no changes to the config file are needed.In addition, I also added an expiration time (
x_security_token_expires) to the AWS credentials file to match the existing feature insaml2aws.Finally, I updated the tests to use
pytestsincenosedoes not support Python 3.10+ and dropped support for Python 3.6 since there were incompatibilities with some of the libraries we use.Please note: This change does not support non-interactive logins, which not currently possible with OIE. Once Okta has a solution for non-interactive logins, support for that will be added.
Related Issue
345
365
329
Motivation and Context
OIE support in gimme-aws-creds is a requirement before we can migrate to OIE.
How Has This Been Tested?
Tested against an OIE and classic domains. All existing functionality on the classic domain is still working.
Screenshots (if appropriate):
N/A
Types of changes
Checklist: