miki3421 commented on issue #271:
URL: https://github.com/apache/openserverless/issues/271#issuecomment-6200940957
Thanks @col-panic. I checked the implementation, including the task revision
shown in your `ops -info`, and also saw your follow-up question on PR #96.
The kubeconfig was already present in the OPS directory. In your case, the
SSO command was not using it automatically; explicitly setting `KUBECONFIG`
resolved that connection issue. Your output confirms that the SSO configuration
was applied successfully, although an actual SSO login still needs to be
verified.
Regarding groups versus roles, the distinction is:
- The current configuration command **requires `--required-group`**.
- The backend checks whether that value appears in the claim selected by
`--groups-claim`, which defaults to `groups`.
- That check does not distinguish a Keycloak group from a role mapped into a
token claim. It is an admission check, not a mapping of Keycloak roles to OPS
administrative permissions. In particular, the value `admin` does not itself
grant an OPS administrator role.
The guide uses a Group Membership mapper because it produces the claim
expected by the default configuration. That should not be presented as a
general requirement of OIDC or as a recommendation against realm/client roles.
If you prefer roles, the current validator can consume a **top-level claim
containing the permitted role names**, populated by an appropriate Keycloak
mapper. For example, with this claim in the access token:
```json
{
"ops_roles": ["openserverless-access"]
}
```
the corresponding options would be:
```text
--groups-claim=ops_roles --required-group=openserverless-access
```
However, the validator currently performs a direct top-level claim lookup.
It does **not** traverse nested paths such as `realm_access.roles` or
`resource_access.openserverless.roles`. Passing those strings to
`--groups-claim` would not read the nested roles.
There is also a distinction between the backend and the configuration
command: the backend skips this membership check if `OIDC_REQUIRED_GROUP` is
unset, but the current command does not expose that as an optional
configuration. So simply omitting `--required-group` is not supported by this
command.
For your update question: **you do not need to delete or disable SSO
first**. Run the same complete `ops config sso keycloak --enable ...` command
again, changing `--required-group` to the new value and retaining your other
options and explicit `KUBECONFIG`. It reapplies the configuration and restarts
the admin-api by default.
Please include your existing `--client-secret` again when doing this. In the
task revision you are using, omitting it switches the configuration to
public-client mode and deletes the managed SSO Secret; it does not retain the
previous secret. Likewise, retain any non-default audience or claim options.
We will update the guide in PR #96 to clarify the distinction between
Keycloak groups and role claims, the current limitation on nested claims, and
how to update an existing SSO configuration—including the need to pass the
client secret and any non-default options again.
Code references: [configuration task at your
revision](https://github.com/apache/openserverless-task/blob/7981be97d0b8df4fa7453ff493b3cb65c4117ebf/config/sso/sso.ts#L147-L172)
and [backend membership
validation](https://github.com/apache/openserverless-admin-api/blob/0.9.0/openserverless/common/oidc_validator.py#L130-L141).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
