Statnett-255: OBO authentication against Cognite for the chat bot backend app

[nelly-hateva]

No description provided.

[tonyKunchev]

It looks good, at least from what I can understand 😅

[nelly-hateva]

It looks good, at least from what I can understand 😅

When I get access to Cognite and test the access from Jupyter Notebook on RNDP and from my dev machine, I will proceed with merging and releasing a new RC, then we can deploy to RNDP and test. I doubt it will work, but I'm not sure what else to do :(

[nelly-hateva]

@mihailradkov @tonyKunchev @boyan-tonchev I've tested this locally with the RNDP configurations from Misho https://github.com/statnett/Talk2PowerSystem_PM/pull/275/files#diff-5a2250121396dd1c2098dafce92a1744bcad0b71025b8eee28e2dcdd808fdfdbR76, and what I now understand is that currently, the frontend is sending to the backend the id_token. But OBO doesn't work with id_token, it expects access_token. The access_token is also available to the frontend. I'm not sure what's the correct approach here - the frontend to send both to the backend or to send only the access_token.

[tonyKunchev]

@mihailradkov @tonyKunchev @boyan-tonchev I've tested this locally with the RNDP configurations from Misho https://github.com/statnett/Talk2PowerSystem_PM/pull/275/files#diff-5a2250121396dd1c2098dafce92a1744bcad0b71025b8eee28e2dcdd808fdfdbR76, and what I now understand is that currently, the frontend is sending to the backend the id_token. But OBO doesn't work with id_token, it expects access_token. The access_token is also available to the frontend. I'm not sure what's the correct approach here - the frontend to send both to the backend or to send only the access_token.

Neli, how does the frontend receives these tokens? Is there a different authentication workflow for the backend and frontend or is it a matter of calling auth endpoints with specific tokens/secrets?

[nelly-hateva]

Neli, how does the frontend receives these tokens? Is there a different authentication workflow for the backend and frontend or is it a matter of calling auth endpoints with specific tokens/secrets?

The frontend is using the msal library to obtain the tokens, both tokens are obtained within the same call. Boyan already modified the frontend to send the access_token to the backend instead of the id_token (statnett/Talk2PowerSystem_UI#37).

The backend auth flow is modified to use OBO for Cognite. So, currently the expected behavior is:

• There are two registered apps in Azure - one for the front end (SECURITY_FRONTEND_APP_CLIENT_ID) and one for the backend (SECURITY_CLIENT_ID)
• The frontend requests access token and sends it to the backend
• The backend uses the access token for the user to obtain on behalf of (OBO) this user token for Cognite

[tonyKunchev]

I see. Is it enough for the frontend to pass the other token as well or do we need something more specific as flow?

My guess is that there will be no issue in providing all tokens to the backend, although I am not sure how we are going to handle token refreshes and expiration. Have to check what does this frontend library does. We may need to implement or find similar library for the backend in order to avoid the mentioned issues.

[nelly-hateva]

My guess is that there will be no issue in providing all tokens to the backend, although I am not sure how we are going to handle token refreshes and expiration. Have to check what does this frontend library does. We may need to implement or find similar library for the backend in order to avoid the mentioned issues.

There is no need to provide both tokens. As far as I understand the good practice is to pass the access token , not the id token. The id token basically says "this is user X", while the access token carries information such as "user X has access to Cognite, to GraphDB, but not to some service Y".

For the backend we use msal and python-jose. python-jose is used to verify the access token (the refresh and expiration are handled by the frontend app, which keeps the sessions) https://github.com/statnett/Talk2PowerSystem_LLM/pull/64/changes#diff-adcdb97740de29ad481ff42377f6050ed75eeb813cdf111ea58e650789c1efbaR51 . msal is used to obtain tokens for Cognite and according to the documentation it handles the refresh and expiration - https://github.com/statnett/Talk2PowerSystem_LLM/pull/64/changes#diff-9826184a8a506f2abbd9363a3f3b5d84d3e1c5154708eeeac2725996f76f4896R440

[nelly-hateva]

@tonyKunchev Please, advise if we need to modify the helm chart. Here, we add a new configuration property, which we read from the agent.yaml file .

[nelly-hateva]

Please, also check the two new configuration properties described in the file docs/FastAPI.md

[tonyKunchev]

I'll review the request again, because I've lost some context and check if any updates to the chart are needed.

[tonyKunchev]

I think the chart is flexible enough to allow passing these new configurations without the need of modification. However, I think this one tools.cognite.client_secret should be passed as environment variable, if it is a secret. Otherwise, we have to set it as plain text in the agent config or chart configuration section, which is a bad practice.

[nelly-hateva]

The corresponding environment variable name is COGNITE_CLIENT_SECRET

[tonyKunchev]

Regarding the access and/or id tokens, we just need to do a small change in the frontend to provide the correct token, if I am understanding it correctly.
Do we need additional task or more details?

[nelly-hateva]

Regarding the access and/or id tokens, we just need to do a small change in the frontend to provide the correct token, if I am understanding it correctly. Do we need additional task or more details?

This is done statnett/Talk2PowerSystem_UI#37