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

okta: make extra efforts to extract risk information from debug_data #4806

Merged
merged 1 commit into from
Dec 14, 2022

Conversation

efd6
Copy link
Contributor

@efd6 efd6 commented Dec 13, 2022

What does this PR do?

The format used by Okta in the debug data fields are not generally parsable with a kv processor, but the risk level and reason fields in are of enough value to make some extra effort to recover if the kv processor failed. In this case also retain the original object in case there were other fields in the object.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Screenshots

@efd6 efd6 added bug Something isn't working, use only for issues Team:Security-External Integrations Integration:okta Okta labels Dec 13, 2022
@efd6 efd6 self-assigned this Dec 13, 2022
@elasticmachine
Copy link

elasticmachine commented Dec 13, 2022

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2022-12-14T09:43:38.351+0000

  • Duration: 14 min 29 sec

Test stats 🧪

Test Results
Failed 0
Passed 7
Skipped 0
Total 7

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@elasticmachine
Copy link

elasticmachine commented Dec 13, 2022

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (1/1) 💚
Files 100.0% (1/1) 💚
Classes 100.0% (1/1) 💚
Methods 100.0% (18/18) 💚 14.286
Lines 86.689% (521/601) 👎 -12.116
Conditionals 100.0% (0/0) 💚

@efd6 efd6 marked this pull request as ready for review December 13, 2022 00:32
@efd6 efd6 requested a review from a team as a code owner December 13, 2022 00:32
@elasticmachine
Copy link

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

Copy link
Contributor

@kcreddy kcreddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor clarification and need to fix merge conflicts. LGTM 👍🏼

The format used by Okta in the debug data fields are not generally
parsable with a kv processor, but the risk level and reason fields in
are of enough value to make some extra effort to recover if the kv
processor failed. In this case also retain the original object in case
there were other fields in the object.
@elasticmachine
Copy link

Package okta - 1.12.1 containing this change is available at https://epr.elastic.co/search?package=okta

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working, use only for issues Integration:okta Okta
Projects
None yet
3 participants