Closed RowanErasmus closed 11 months ago
@RowanErasmus - from discussion on Atlas WG, we'd like to consider these changes in light of the discussion on #1473 and #1884. If your team needs to use this, please use this side-branch you've developed here but we'll want to consider these requirements when we develop the design for those issues.
I think we also discussed that this functionality may have a use-case, so we can incorporate this change for use when you want to authenticate via OID, and the separate functionality of API Keys (which can bypass authentication) which is discussed in the different PR.
@anthonysena , if you agree, can we move forward with merging this PR?
I think we also discussed that this functionality may have a use-case, so we can incorporate this change for use when you want to authenticate via OID, and the separate functionality of API Keys (which can bypass authentication) which is discussed in the different PR.
@anthonysena , if you agree, can we move forward with merging this PR?
Agreed - I'll approve this PR with the note that it is handling a specific use-case vs the other referenced issues which is a broader solution.
Are there any new security parameters we should cover with Broadsea?
I don't believe so. It adds a new path /user/login/openidDirect
which can be used for direct API access with OpenID.
The OpenID Connect story continues.
As per this issue #2288 we are trying to access WebAPI programmatically and the current OIDC implementation only allows the code flow through the UI, this adds the option to authenticate with a token supplied by the identity provider.
I think, as far as the needs of EMC go, with this we are now at a fully functional OIDC implementation for WebAPI :-)