Add more flexibility to authorization unique identifier expectations

rbclark commented 2 years ago

The current code just assumes the unique identifier responds to client ID and issuer. That is currently the case however it is potentially a flawed assumption with new authentication methods being added going forward.

Description

I am currently working to add support to the googleauth library for Workload Identity Federation. As part of this, I am adding a new type of authentication to the googleauth library itself. It is currently assumed that the authorization responds to client_id and issuer, and if either of these are not present then train exits with a stacktrace. This small changes makes train more flexible regarding the authorization object.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New content (non-breaking change)
[ ] Breaking change (a content change which would break existing functionality or processes)

Checklist:

[x] I have read the CONTRIBUTING document.

chef-expeditor[bot] commented 2 years ago

Hello rbclark! Thanks for the pull request!

Here is what will happen next:

Your PR will be reviewed by the maintainers.
Possible Outcomes a. If everything looks good, one of them will approve it, and your PR will be merged. b. The maintainer may request follow-on work (e.g. code fix, linting, etc). We would encourage you to address this work in 2-3 business days to keep the conversation going and to get your contribution in sooner. c. Cases exist where a PR is neither aligned to Chef InSpec's product roadmap, or something the team can own or maintain long-term. In these cases, the maintainer will provide justification and close out the PR.

Thank you for contributing!

rbclark commented 2 years ago

Sorry to be a bother but would it be possible for someone to take a look at this and let me know if it needs any changes?

inspec / train