okta: add extended okta.debug_context.debug_data handling

[efd6]

What does this PR do?

This adds additional handling of the debug_context.debug_data object and particularly the risk level field that is in that 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

• Consider whether to move fields in okta.debug_context.debug_data.flattened.logOnlySecurityData to okta.debug_context.debug_data.flattened to make the structure of okta.debug_context.debug_data agnostic to the original event's structure.

How to test this PR locally

Run elastic-package test in the okta package.

Related issues

• Relates [Filebeat][Okta] Parse additonal debug data risk field for Okta module beats#30961

Screenshots

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-05-19T04:00:05.256+0000

• Duration: 14 min 3 sec

Test stats 🧪

Test	Results
Failed	0
Passed	12
Skipped	0
Total	12

🤖 GitHub comments

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

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (1/1)	💚
Files	100.0% (1/1)	💚 3.731
Classes	100.0% (1/1)	💚 3.731
Methods	100.0% (17/17)	💚 11.9
Lines	86.69% (495/571)	👎 -2.801
Conditionals	100.0% (0/0)	💚

[efd6]

@ynirk PTAL

[elasticmachine]

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

[ynirk]

LGTM

[efd6]

@ynirk I was wondering if you think it would be worth moving the okta.debug_context.debug_data.flattened.logOnlySecurityData object to okta.debug_context.debug_data.flattened if it exists. This would make the document the same for both cases in that set of fields independent of the original. We could mark that there was originally a logOnlySecurityData if that is informative.

[r00tu53r]

LGTM!

[ynirk]

I was wondering if you think it would be worth moving the okta.debug_context.debug_data.flattened.logOnlySecurityData object to okta.debug_context.debug_data.flattened

sorry @efd6 I missed your last ping. It could have been a good idea but I suppose it's too late now

[efd6]

The change here reflects the situation in the filebeat module and that was merged three weeks ago, so we are sort of stuck with this.