Skip to content
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

[Meta] Deprecating Exchange Online Basic Authentication #112151

Open
8 of 9 tasks
YulNaumenko opened this issue Sep 14, 2021 · 1 comment
Open
8 of 9 tasks

[Meta] Deprecating Exchange Online Basic Authentication #112151

YulNaumenko opened this issue Sep 14, 2021 · 1 comment
Assignees
Labels
Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX Feature:Actions/Framework Issues related to the Actions Framework Meta Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@YulNaumenko
Copy link
Contributor

YulNaumenko commented Sep 14, 2021

  1. Initial issue was created by the community, based on the info from Microsoft about deprecating basic auth for exchange
  2. Based on the options, which Microsoft gave us for authenticating SMTP integration application, the next step was to do the research issue for supporting generic OAuth 2.0 Authorization Code flow. Based on that we created POC. In addition to the POC, we created RFC for supporting generic OAuth 2.0 Authorization Code flow across Kibana and the proper issues for implementation: [Actions] Extend email action connector schema to support OAuth properties in config/secrets.  #107898, [Actions] Implement ability to identify the email server (Gmail, Outlook, etc.) in the email connector configuration.  #107846, Create Kibana callback endpoint for OAuth requests. #107847, [Connectors] Implement UI part for OAuth configuration for email MS Exchange connector. #107918, [Connectors Docs] Extend existing email connector MS Exchange documentation with new authorization option OAuth 2.0 Authorization Code Flow  #107904. Those was closed later in favor of the other approach.
  3. As an alternative to the implementing OAuth 2.0 Authorization Code flow, was done the research on the usage OAuth 2.0 Client Credentials flow, which is more server to server communication sufficient. The main Cons here is a stepping out of the current SMTP integration in favor of MS Exchange specific way of sending emails based on MS Graph API. Created POC
  4. Other OAuth 2.0 alternatives research:

Based on the comparison of the different research results, the team made the decision to move with implementing OAuth 2.0 Client Credentials flow and using MS Graph API for sending emails for MS Exchange Server service provider.
Summary with pros and cons: #93466 (comment)

In addition to the fixing cons about non-generic way of sending emails for MS Exchange, Microsoft has on the roadmap to add OAuth 2.0 Client Credentials support for SMTP integration.

For the selected approach opened next implementation issues:

@YulNaumenko YulNaumenko added Meta Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Actions/Framework Issues related to the Actions Framework Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX labels Sep 14, 2021
@YulNaumenko YulNaumenko self-assigned this Sep 14, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions/ConnectorsManagement Issues related to Connectors Management UX Feature:Actions/Framework Issues related to the Actions Framework Meta Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

3 participants