-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Actions] Add RESTful OAuth support for action types by adding new SO for access/refresh token info storage. #94768
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
A couple of questions:
|
Thanks for the ping! It's not my place to dictate process, but I think an RFC would be appropriate here. I have a very high level understanding of what we're trying to do, so having a detailed design doc that describes the problem we're trying to solve, and how we intend to solve it would be helpful to me. |
We were thinking it would be better to keep these in a separate SO, otherwise the connector SO's will end up getting updated by the system as the tokens are refreshed, etc. Also, if we require schema changes to whatever data we're storing, it's one change vs N connector changes. |
Yeah, I tend to agree @legrego.
Fair points @pmuellr , I was just trying to reduce the overhead caused by maintaining multiple SOs that have these very weak links 😕 |
Good question - for the case of connectors that have multiple actions (ie, the case-related ones), I think 1-1 relationship is fine. But you could imagine a story where someone has multiple connectors to the same product, where the OAuth grants could be shared, if that's what the customer wanted to do. Would make it easier to configure - just do it once, share amongst the other connectors (somehow). My main concern with a separate SO was to keep the mutations on the connectors to a minimum (the SO updated date will change every time we refresh a token), and keep from having to migrate N connector types that might use this, if the OAuth props need to be updated. |
Indeed this is exactly what I had in mind for #94518 |
This issue is related to the research #93466 |
Closing as we now have a storage mechanism. |
Based on the investigation done in the issue,
we were planning to use a common storage with the problem for tls/ssl, but then we found out that this is a different tasks and should be implemented independently.
From this point, we decided to provide a new SO to store the grant info for all OAuth connections.
There is a couple of thoughts from @pmuellr:
Presumably it would be keyed off the connector id. Which means after a connector is deleted, we should also delete the grant info SO.
We could do this specifically in the connector delete logic - not sure if there's a reason why we would want to keep an old version around.
What happens if a user switches from user/pass to OAuth then back to user/pass then back to OAuth - should we keep all the OAuth info around? Seems like we probably would.
The text was updated successfully, but these errors were encountered: