forgerock: use dynamic mappings for object fields

[efd6]

Proposed commit message

See title.

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

• Closes [forgerock] Use more specific field mappings #8046

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: 2023-10-03T02:57:09.108+0000

• Duration: 20 min 7 sec

Test stats 🧪

Test	Results
Failed	0
Passed	56
Skipped	0
Total	56

🤖 GitHub comments

Expand to view the GitHub comments

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

• /test : Re-trigger the build.

[efd6]

I left the specific forgerock.request.detail.* fields here and below for the documentation they provide. It's not clear to me whether this breaks the dynamic mapping. The same situation is in the specific forgerock.response.detail.* fields below.

It looks to me like it is OK.

      "dynamic_templates": [
        {
          "forgerock.request.detail.*": {
            "path_match": "forgerock.request.detail.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "forgerock.http.request.headers.*": {
            "path_match": "forgerock.http.request.headers.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "forgerock.http.request.queryParameters.*": {
            "path_match": "forgerock.http.request.queryParameters.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "forgerock.response.detail.*": {
            "path_match": "forgerock.response.detail.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "strings_as_keyword": {
            "match_mapping_type": "string",
            "mapping": {
              "ignore_above": 1024,
              "type": "keyword"
            }
          }
        }
      ],

[efd6]

Deleted as it is only here for testing AFAICS. Same for the ... .after. ... case.

[efd6]

      "dynamic_templates": [
        {
          "forgerock.before.*": {
            "path_match": "forgerock.before.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "forgerock.after.*": {
            "path_match": "forgerock.after.*",
            "mapping": {
              "type": "keyword"
            }
          }
        },
        {
          "strings_as_keyword": {
            "match_mapping_type": "string",
            "mapping": {
              "ignore_above": 1024,
              "type": "keyword"
            }
          }
        }
      ],

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (11/11)	💚
Files	100.0% (11/11)	💚
Classes	100.0% (11/11)	💚
Methods	100.0% (101/101)	💚 0.699
Lines	96.489% (962/997)	👍 24.226
Conditionals	100.0% (0/0)	💚

[elasticmachine]

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

[kgeller]

LGTM

If you're interested in even more validation, I think we have creds in the vault for the testing instance they gave access to for development

[elasticmachine]

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