@Yee and @Haytham Abuelfutuh I have a question about the okta setup. Flyte docs mentioned the creation of custom okta authorization server with the following custom settings - custom scopes (all and offline) and a custom auth server. I’ve experimented with it and this is what I’ve found:
- the offline scope is for using refresh_token. Okta has a built-in scope for that called offline_access, which is sent back to the client if you add the Refresh Token grant to your app. This works for the default auth server.
- the all scope is custom. We can create it via the default auth server. However we can create it via a custom auth server as well. Some okta org admins do not want to add custom scopes in the default auth server and keep it as vanilla as possible. I noticed that the all scope is hardcoded in the flyteadmin auth interceptor, so if we don’t pass it, okta auth does not work as expected.
- custom audience is optional, meaning that since flyte requires is to create a custom auth server with custom scopes, we might as well change the audience from the default of api://default. By default okta returns an audiance equal to your clientId authenticating to Okta. We can set whatever audience we expect in the flyteadmin confing (auth.appAuth.externalAuthServer.allowedAudience) so we can use the default setting.
My question is why the all scope is needed and how can we configure flyte okta auth against an okta server with only the default auth server available.
10/19/2023, 2:29 PM
remind me again where you see the all scope? i feel like that’s configurable.
did you try without it?
10/19/2023, 7:17 PM
Yes, I did. It does not work as it’s hardcoded in flyteadmin
i will show you
the client (flytectl/pyflyte) contacts the admin and the admin tells it what scopes to request and the idp baseurl. However the all scope (+ the offline scope) are required otherwise the admin rejects the connection with an error.
I think this is the user login path. When you login through the UI, i think the idea was that a user should have “all” the capabilities that that user’s identity is allowed to have... The idea was that in OSS we can define one of a handful of scopes (all, proj admin, user, viewer) or something and then if you configure your IDP to issue the right scopes, flyte could ultimately do some very very lightweight/entrylevel AuthZ based on these scopes. this never happened so we just have this single scope that Admin expects for all methods...
but this “all” is from Admin’s perspective, not the perspective of the rest of the idp or other applications the idp might be used for.
i think it is okay to make this configurable.
do you think you could put in a PR?
10/23/2023, 10:16 AM
i am not that good with golang
but I agree that this should be configurable, cause it places a hard requirement on the idp to do custom setup in order to be able to do blanket auth. Currently not all Idp admin would like to add custom scopes, so at the very least if flyte wants to use idp as okta as authz solution, the scopes that we require should be configurable.
currently we pass the required scopes by default to the client via the flyteadmin metadata service anyway