-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow domain names or IDs in keystone connector #3506
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cardoe thanks, idea looks great. Could you check why tests didn't pass?
--- FAIL: TestValidUserLogin (3.44s)
--- PASS: TestValidUserLogin/test_with_email_address (1.00s)
--- PASS: TestValidUserLogin/test_without_email_address (0.99s)
--- FAIL: TestValidUserLogin/test_with_domain_ID (0.51s)
--- FAIL: TestValidUserLogin/test_with_domain_Name (0.52s)
Absolutely. Thank you for catching that. |
It's cause the dex project has actual good tests and is testing against a real keystone while I fudged it in the tests and had hand added the data into my local keystone. So 👍 on having a good test environment. I'll clean this up and improve the test coverage. Thanks again for the review. |
OpenStack Keystone allows a user to authenticate against a domain. That domain can be specified either as the domain ID or the domain name when authenticating. The domain ID is a UUID or the special "default" domain ID so key off of that when deciding what to submit to the keystone API. Collapsed the code to share the domainKeystone struct by utilizing omitempty to skip unset fields. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
I've now tested it with the rocky container used in the tests as well as my local keystone. |
I've also rebased and fixed up for the log changes that happened recently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Thanks for your contribution, @cardoe!
OpenStack Keystone allows a user to authenticate against a domain. That domain can be specified either as the domain ID or the domain name when authenticating. The domain ID is a UUID or the special "default" domain ID so key off of that when deciding what to submit to the keystone API. Collapsed the code to share the domainKeystone struct by utilizing omitempty to skip unset fields.