https://flyte.org logo
Powered by
#ask-the-community
Title
# ask-the-community
g

Georgi Ivanov

10/18/2023, 2:26 PM
@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.
y

Yee

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?
g

Georgi Ivanov

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.
let me show you what I mean
We configure the PluginRegistry with Blanket Authorization https://github.com/flyteorg/flyte/blob/master/flyteadmin/pkg/server/service.go#L80 In the BlanketAuthorization function we check if the identity context has ScopeAll https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/interceptor.go#L21 which is currently set to “all” https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/constants.go#L24 since “all” is a custom scope we need to add it to either the default authorization server or a custom one. I successfully tested with an okta dev account and adding both “all” and “offline” scopes to the list of available scopes (so they can be requested) worked for pyflyte/flytectl. However not all Okta admins are willing to add custom scopes to the default auth server. For the userauth path (i.e. from the flyteconsole) we autoinject the “all” scope in the context created from the id_token, i.e the console/admin app using the flyteconsole okta app with openid,profile scopes. https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/token.go#L134 https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L283 But for the identity context created from access_token we don’t, so unless we have the “all” scope returned from okta as we have hardcoded the check in the admin, we will fail the client with “authenticated user doesn’t have required scope” https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L276 https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/token.go#L75 Why do we need this in the first place? I mean do we really need custom scopes and can we make this configurable?
@Yee
it all came from the original commit that introduced the oauth support by @Haytham Abuelfutuh
y

Yee

10/20/2023, 12:47 PM
let me see what i can dig up
g

Georgi Ivanov

10/21/2023, 10:49 PM
thanks, seem to me that “all” is a placeholder for some kind of a blanket auth, i.e. admin level access - https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/interceptor.go#L21
y

Yee

10/23/2023, 1:03 AM
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?
g

Georgi Ivanov

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
y

Yee

10/23/2023, 11:19 PM
mind putting in an issue?
g

Georgi Ivanov

10/31/2023, 4:58 PM
ok, will do that
3 Views
Powered by