https://flyte.org logo
Join Slack
Powered by
Hello. I'm investigating an issue where the user i...
# flyte-support
c
Hello. I'm investigating an issue where the user identity for Flyte Console based requests always seems to be our Flyte Console Okta App ID (despite logging in as an Okta user). This breaks the "view my executions" filter pretty heavily. From the limited investigation I've done I've noticed that Flyte Console only seems to have ID tokens related cookies and no access token related cookies. I'm curious if anyone else has any ideas why this is the case before I dig further into the code. I validated that the login flow with Okta produces both an ID token and an access token. The access token is the one with a proper user subject claim.
Hmm that seems like a bug because there is code to delete/retrieve the access token cookie but never any code that writes it
t
is it not?
isn’t that what this does?
or am i missing something
c
I think you're right. I need to investigate some more
Yeah the access token is definitely available.. I wonder why filtering by execution IDs results in a request like 
api/v1/executions/inference/development?filters=eq(user,00udlb1wsfEdsiMGs1d7)&limit=100&sort_by.direction=DESCENDING&sort_by.key=created_at
Need to figure out how flyte console determines what user it is
Copy code
const profile = useUserProfile();
  const apiContext = useFlyteApi();
  const userId = profile.value?.subject ?? '';
t
is it in 
/me
make that other ticket also when you get a chance plz
would be most grateful. helps us keep track when the person who’s actually going to benefit is the issue creator
c
Yeah so 
/me
which I can't find in flyteadmin yet seems to return the id token which is my problem
Where is this 
/me
handler defined?
Ah its grpc-gateway and not on the http server got it
Ah ok so this pulls from the identity context... which seems to be populated from the ID token which is not what I want..
I'll report back after looking some more
Looks like when the requests gets to the gRPC layer the header is 
Authorization: IDToken ...
But my UI doesn't send that, so its getting set somewhere in the middleware
OK I'm fairly certain this is the reason: https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L353-L396 This gateway middleware only ever sets the ID token scheme and never the Bearer scheme with the access token
So once the requests hits the gRPC later you'll always see id token related identity (subject claim) instead of access token related identity
t
you’re saying the identity provided in the id token is different than the identity provided by the access token?
but why does that matter? if the whole system is using one id?
c
Well for Okta the subject claim will be different between the tokens. For the ID token the subject is 
00udlb1wsfEdsiMGs1d7
(okta app id) and for access token its 
<mailto:jparraga@stackav.com|jparraga@stackav.com>
https://devforum.okta.com/t/why-is-the-sub-claim-in-the-access-token-and-id-token-different/3978
It matters for a couple reasons 1. It breaks the "filter my executions" feature in the UI 2. Any execution triggered by the UI is triggered under the same global user
Right now our situation is that all 
pyflyte
executions have proper users attached to them but all the ones triggered in the UI have the global ID
And we're trying to plumb some of that identity info to our plugin as well
We also requests from our team to show the owner of the execution in the UI
Based on the auth interceptor logic it looks like it always prefers access token and falls back to ID token: https://github.com/flyteorg/flyte/blob/master/flyteadmin/auth/handlers.go#L297-L328
Interestingly I'm getting a 401 because the access token doesn't have scope "all" heh.
Alright setting the 
Bearer: accessToken...
in the http middleware worked for me woo
6 Views
Open in Slack
PreviousNext
Powered by