[ResponseOps][Connectors] Use profileUid in actions client#254589
Conversation
…a into issue-251047-use-profile-uid-task-exe_stack
…a into issue-251047-use-profile-uid-task-exe_stack
…a into issue-251047-use-profile-uid-task-exe_stack
lorenabalan
left a comment
There was a problem hiding this comment.
Small qs & nits but LGTM otherwise
x-pack/platform/plugins/shared/actions/server/routes/oauth_callback.test.ts
Show resolved
Hide resolved
| return null; | ||
| } | ||
|
|
||
| const token = connectorToken as ConnectorToken; |
There was a problem hiding this comment.
Why not keep the casting here but add the | UserConnectorToken? Wouldn't it be valid for L182-185 too?
There was a problem hiding this comment.
typescript wouldn't complain, but I think it's unnecessary because the properties we use (expiresAt/refreshTokenExpiresAt) exist in both types. It's also dangerous for us, hypothetically, you could have a per-user token here and the type would allow you to cast it as a ConnectorToken, but it would be wrong because per-user tokens have no top level token/refreshToken
x-pack/platform/plugins/shared/actions/server/lib/get_oauth_authorization_code_access_token.ts
Show resolved
Hide resolved
| accessToken: string | null; | ||
| refreshToken: string | undefined; |
There was a problem hiding this comment.
Why do we have this distinction null vs undefined, rather than both undefined? 🤔
There was a problem hiding this comment.
you can see null as "unexpected shape" error, whereas undefined means it's ok but just not set
...platform/plugins/shared/actions/server/lib/get_oauth_authorization_code_access_token.test.ts
Show resolved
Hide resolved
js-jankisalvi
left a comment
There was a problem hiding this comment.
Tested locally with google drive workflow, works as expected 🎉
…com:jcger/kibana into issue-251047-use-profile-uid-task-exe_stack
47b9df6 to
1907ce9
Compare
1d06d8e to
14a0a7e
Compare
ad54e5c to
c7ac44d
Compare
20719b9 to
e7e0dd0
Compare
…a into issue-251047-use-profile-uid-task-exe_stack
c7ac44d to
7bfc7a7
Compare
💔 Build Failed
Failed CI Steps
Test Failures
Metrics [docs]
History
|
82a2597
into
elastic:connectors-auth-code-grant
|
Merging because CI errors seem to come from the feature branch, not this one |
## Description
Currently, all Kibana connectors use a shared service account for
authentication. This approach lacks per user level access support, as it
does not distinguish between individual users and service account user
levels of permission. To support more secure, flexible, and user-aware
integrations, we need to introduce per-user authentication for
connectors in Kibana, alongside the existing service account method.
## 2-step release
As there are changes that require a 2-step release, this PR won't add
`oauth_authorization_code` auth type to any connector type. Therefore,
it won't be usable for now. The changes that require a 2-step release
are:
- we are adding `refreshTokenExpiresAt` to AAD for `connector_token` SO
- we are adding `refreshToken` as an encrypted attribute for
`connector_token` SO
## Config to run this locally
```
uiSettings:
overrides:
'workflows:ui:enabled': true
server.publicBaseUrl: 'http://localhost:5601'
```
Also, the auth type needs to be used in a connector. Reach out privately
to get the necessary info.
## Involved PRs:
- #246655
- #251873
- #251717
- #252566
- #252104
- #252307
- #252262
- #252501
- #253606
- #254589
- #254916
- Rename rate limit kbn setting 15d2c19
- Fix refresh token 34708e5
---------
Co-authored-by: Sean Story <sean.story@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lorena Bălan <lorena.balan@elastic.co>
Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: Dennis Tismenko <dennis.tismenko@elastic.co>
## Description
Currently, all Kibana connectors use a shared service account for
authentication. This approach lacks per user level access support, as it
does not distinguish between individual users and service account user
levels of permission. To support more secure, flexible, and user-aware
integrations, we need to introduce per-user authentication for
connectors in Kibana, alongside the existing service account method.
## 2-step release
As there are changes that require a 2-step release, this PR won't add
`oauth_authorization_code` auth type to any connector type. Therefore,
it won't be usable for now. The changes that require a 2-step release
are:
- we are adding `refreshTokenExpiresAt` to AAD for `connector_token` SO
- we are adding `refreshToken` as an encrypted attribute for
`connector_token` SO
## Config to run this locally
```
uiSettings:
overrides:
'workflows:ui:enabled': true
server.publicBaseUrl: 'http://localhost:5601'
```
Also, the auth type needs to be used in a connector. Reach out privately
to get the necessary info.
## Involved PRs:
- elastic#246655
- elastic#251873
- elastic#251717
- elastic#252566
- elastic#252104
- elastic#252307
- elastic#252262
- elastic#252501
- elastic#253606
- elastic#254589
- elastic#254916
- Rename rate limit kbn setting 15d2c19
- Fix refresh token 34708e5
---------
Co-authored-by: Sean Story <sean.story@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lorena Bălan <lorena.balan@elastic.co>
Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: Dennis Tismenko <dennis.tismenko@elastic.co>
## Description
Currently, all Kibana connectors use a shared service account for
authentication. This approach lacks per user level access support, as it
does not distinguish between individual users and service account user
levels of permission. To support more secure, flexible, and user-aware
integrations, we need to introduce per-user authentication for
connectors in Kibana, alongside the existing service account method.
## 2-step release
As there are changes that require a 2-step release, this PR won't add
`oauth_authorization_code` auth type to any connector type. Therefore,
it won't be usable for now. The changes that require a 2-step release
are:
- we are adding `refreshTokenExpiresAt` to AAD for `connector_token` SO
- we are adding `refreshToken` as an encrypted attribute for
`connector_token` SO
## Config to run this locally
```
uiSettings:
overrides:
'workflows:ui:enabled': true
server.publicBaseUrl: 'http://localhost:5601'
```
Also, the auth type needs to be used in a connector. Reach out privately
to get the necessary info.
## Involved PRs:
- elastic#246655
- elastic#251873
- elastic#251717
- elastic#252566
- elastic#252104
- elastic#252307
- elastic#252262
- elastic#252501
- elastic#253606
- elastic#254589
- elastic#254916
- Rename rate limit kbn setting 15d2c19
- Fix refresh token 34708e5
---------
Co-authored-by: Sean Story <sean.story@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lorena Bălan <lorena.balan@elastic.co>
Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: Dennis Tismenko <dennis.tismenko@elastic.co>
Summary
Closes #251047
Adds a getCurrentUserProfileId method to the Actions plugin so OAuth authorization-code connectors can use the user’s profile UID when running in per-user auth mode. Like proposed by the PoC bcb8207#diff-77a930ac5bc56dbf3f1c1165f9cc35b729e38a36a9b3dae00fc47782ec646b19R615
Add { unknowns: 'allow' } to the query schema so OAuth providers can include extra query parameters (e.g. scope, authuser) in the redirect URL without validation failures.