You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for an issue that matches the one I want to file, without success.
Problem Description
Prior to 2.34, using the admin service for groups was optional. It was implicitly enabled by adding a service account path and an admin email address to the configuration.
2.34 added support for falling back to default credentials which (with some of the changes added in 2.35) introduced a number of issues:
Instead of implicitly enabling the admin service, it became enabled by default and that led to issues in certain environments.
Proposed Solution
Enable the admin service explicitly in configuration (with a fallback to the <2.34 behavior).
Although this would be a breaking change (well, compared to 2.34 and 2.35), it still seems to be the better option given that enabling it by default leads to various issues.
Alternatives Considered
It's worth mentioning that the admin service is currently only required if the groups scope is requested. As a temporary workaround #2700 makes the admin service optional, unless the scope is requested.
With the groups scope requested it seems to be somewhat counterintuitive not to require the admin service. Whether it's a hard or soft requirement (resulting in a warning or a failure) is up for debate.
#2122 implements an interesting alternative where using default credentials is configurable and admin impersonation seems to work better too.
Additional Information
We need a way to verify and test the behavior, preferably using automated tests.
The text was updated successfully, but these errors were encountered:
Preflight Checklist
Problem Description
Prior to 2.34, using the admin service for groups was optional. It was implicitly enabled by adding a service account path and an admin email address to the configuration.
2.34 added support for falling back to default credentials which (with some of the changes added in 2.35) introduced a number of issues:
Instead of implicitly enabling the admin service, it became enabled by default and that led to issues in certain environments.
Proposed Solution
Enable the admin service explicitly in configuration (with a fallback to the <2.34 behavior).
Although this would be a breaking change (well, compared to 2.34 and 2.35), it still seems to be the better option given that enabling it by default leads to various issues.
Alternatives Considered
It's worth mentioning that the admin service is currently only required if the
groups
scope is requested. As a temporary workaround #2700 makes the admin service optional, unless the scope is requested.With the
groups
scope requested it seems to be somewhat counterintuitive not to require the admin service. Whether it's a hard or soft requirement (resulting in a warning or a failure) is up for debate.#2122 implements an interesting alternative where using default credentials is configurable and admin impersonation seems to work better too.
Additional Information
We need a way to verify and test the behavior, preferably using automated tests.
The text was updated successfully, but these errors were encountered: