[ForgeRock] Fix IDM Activity revision field format

[chrisberkhout]

What does this PR do?

Fixes the ForgeRock integration's IDM Activity revision field to be keyword rather than integer type, and asserts a hit_count in the corresponding system test. The wrong field type was causing events to be dropped.

I also updated the example values used for the revision field to match the current format shown in ForgeRock's documentation.

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.

Related issues

• Closes [ForgeRock] Event indexing failuring in system test #6178

[elasticmachine]

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

[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-06-12T15:12:39.774+0000

• Duration: 20 min 59 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.

[elasticmachine]

🌐 Coverage report

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

[taylor-swanson]

It looks like the original value was a UUIDv4, but now it's an integer as a string. Did we get the value of this wrong initially?

@kgeller, any thoughts on this (since you originally wrote this)?

[kgeller]

I built this all off of a live test environment that they granted us access to. I just verified again with the API and data from last week still shows that field as a UUID4.

response body

{ "result": [ { "payload": { "_id": "16ec1ce4-f3a6-4517-b28f-24b2430fa113-83532", "after": { "_id": "c544037c-307c-4a5c-bf2b-9019f201b3b0", "_rev": "032ed9ed-6ede-4e3e-aeed-01e77f95d457-2114", "createDate": "2023-06-07T21:25:12.485378Z", "lastChanged": { "date": "2023-06-07T21:25:12.485447Z" }, "loginCount": 2 }, "before": { "_id": "c544037c-307c-4a5c-bf2b-9019f201b3b0", "_rev": "d91720e2-5b0e-4d55-a23b-c3dae4aa1a80-4964", "createDate": "2023-06-07T21:25:12.485378Z", "lastChanged": { "date": "2023-06-07T21:25:12.485447Z" }, "loginCount": 1 }, "changedFields": [], "eventName": "activity", "level": "INFO", "message": "", "objectId": "managed/alpha_usermeta/c544037c-307c-4a5c-bf2b-9019f201b3b0", "operation": "PATCH", "passwordChanged": false, "revision": "032ed9ed-6ede-4e3e-aeed-01e77f95d457-2114", "runAs": "idm-provisioning", "source": "audit", "status": "SUCCESS", "timestamp": "2023-06-08T17:32:25.620Z", "topic": "activity", "transactionId": "1686245545450-c3fb58dad88412fcb665-17563/0/0", "userId": "idm-provisioning" }, "timestamp": "2023-06-08T17:32:25.624676218Z", "type": "application/json", "source": "idm-activity" } ], "resultCount": 1, "pagedResultsCookie": null, "totalPagedResultsPolicy": "NONE", "totalPagedResults": -1, "remainingPagedResults": -1 } 

[chrisberkhout]

Thanks for checking. It's interesting that the live test environment doesn't match their documentation.

The UUID-like values do look like UUIDv4 but with an additional integer component appended.

I don't have a strong opinion about whether we should match the test environment (UUIDv4+integer string) or the documentation (32-bit hex string), but I do think we should index it as a keyword field rather than trying to decode.

[kgeller]

Agreed!

[elasticmachine]

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