miki3421 commented on issue #271: URL: https://github.com/apache/openserverless/issues/271#issuecomment-6373527434
Thanks @col-panic. Your intended flow—an existing Keycloak user logging in for the first time and receiving an OpenServerless namespace—is supported by the SSO provisioning implementation. However, the output you posted shows that the CLI is taking the traditional username/password login path. I checked the source for your exact CLI tag, `v0.9.0-incubating+26i11g51-snapshot` (`d3f767a`). In that version, **the CLI must see `SSO_ENABLED=true`**, from its local configuration or environment. `--sso-flow password` and `--sso-username` select options within SSO mode; they do not enable it. Without that switch, the CLI uses its default `openserverless` user, which explains the output. See the [login branch selection](https://github.com/apache/openserverless-cli/blob/d3f767a66ebd35b570382ef1a32c2866ab2dddd7/auth/login.go#L181-L239). The earlier `ops config sso keycloak --enable ...` command saves SSO settings in the local OPS profile where it runs, as well as configuring the server. A new Docker container does not inherit that local profile. The [task revision reported by your `ops -info`](https://github.com/apache/openserverless-task/blob/7981be97d0b8df4fa7453ff493b3cb65c4117ebf/config/sso/sso.ts#L247-L277) explicitly saves `SSO_ENABLED=true` locally. In the new container, please try: ```sh ./ops -config SSO_ENABLED=true OPS_APIHOST=https://openserverless.somehost.com \ ./ops -login --sso-flow password --sso-username mdescher # After login succeeds: ./ops -wsk action list ``` The login should now print `with backend-managed OIDC password grant` and prompt for `Enter SSO Password:`. Enter the Keycloak user's password. This local configuration command does not reconfigure the cluster or require the Keycloak client secret. Keycloak must allow the password grant for the configured client. For automatic provisioning, the backend validates the token and required membership, derives the namespace from the configured claims, and, if it is missing, creates a `WhiskUser` and waits for the operator to provision it. This requires `SSO_AUTOPROVISION_ON_LOGIN=true`, an `email` claim, and working operator reconciliation. Your [SSO configuration task sets that server flag to true](https://github.com/apache/openserverless-task/blob/7981be97d0b8df4fa7453ff493b3cb65c4117ebf/config/sso/sso.ts#L286-L305). See also the [backend provisioning implementation](https://github.com/apache/openserverless-admin-api/blob/128d00dcbc298aa7307e8f5b0b72e1a24e544e11/openserverless/impl/auth/auth_service.py#L120-L200). In this fresh container, omit a positional OPS username so the backend can resolve the namespace from the identity. The CLI saves the returned credentials for subsequent `ops -wsk` commands. Namespace normalization can apply, so its name is not always identical to the Keycloak username. I verified the relevant CLI and backend unit tests locally, using simulated services. This confirms the implemented behavior, but does not establish which Admin API version is installed on your cluster. If the retry fails, please share the error with secrets redacted and the deployed Admin API image tag or digest. Do not include passwords, tokens, or client secrets. The documentation should make this local activation step and the fresh-container prerequisites explicit. -- 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]
