role arn matching in okta.yaml creates ambiguity
roles in okta.yaml act as if they use "string contains" matching or maybe an implied wildcard.
Example from okta.yaml roles: "arn:aws:iam::.*:role/bu-readonly": "bu-readonly-okta-production"
The above matches multiple roles in the account that start with arn:aws:iam::.:role/bu-readonly and thus creates a confusing list of selectable options.
This can be avoided if we use a $ terminator like "arn:aws:iam::.*:role/bu-readonly$" to ensure it only matches at most once.
We would prefer that a wildcard (*) is required if you want to match multiple roles and not using a * should match only one arn.
I'll take a look at this ...
@eric51893 regexp chars like $ are valid for the idp string e.g. arn:aws:iam::.*:role/bu-readonly$. This is the bit of code that does so:
https://github.com/okta/okta-aws-cli/blob/master/internal/webssoauth/webssoauth.go#L230-L235
I'll update the test https://github.com/okta/okta-aws-cli/blob/master/internal/webssoauth/webssoauth_test.go#L189-L199 to show this
{
name: "regexp friendly label",
alt: "alternate",
arn: "arn:aws:iam::789:saml-provider/aidp",
idps: map[string]string{
"arn:aws:iam::123:saml-provider/youridp": "YourIdP",
"arn:aws:iam::123:saml-provider/myidp": "My IdP",
"arn:aws:iam::.*:saml-provider/aidp$": "A IdP",
"arn:aws:iam::.*:saml-provider/aidp-more": "A IdP more",
},
expected: "A IdP",
},
actually, I'm taking a second look at this.
The implementation of the friendly label (regex patterns for ARNs) is using the MatchString function from golang regexp:
MatchString reports whether the string s contains any match of the regular expression pattern. More complicated queries need to use Compile and the full Regexp interface.
For IdPs: https://github.com/okta/okta-aws-cli/blob/master/internal/webssoauth/webssoauth.go#L232
For Roles: https://github.com/okta/okta-aws-cli/blob/master/internal/webssoauth/webssoauth.go#L444
Given an ARN, a look up the first label that matches that ARN is made given the pattern that matches it. If the regexps are too greedy then they'll need to be adjusted.
This is a convenience feature, I'll help anyone that can submit a PR to adjust the behavior but I'm unable to allocate more time to this.
@monde thank you for the details on how this works. We will adopt use of the $ to terminate our role arns to avoid the greedy(string contains) type of behavior of the MatchString function.