"initiator" in authenticate CADF notifications has an inconsistent meaning

[Zachary Buhman]

Prior to https://opendev.org/openstack/keystone/commit/fd8b5f3206392f210a7240af5b52358791a1df87 , for all Keystone requests, the CADF initiator.id was always either:

- the ID of the authenticating user (if x-auth-token is provided in an /auth/tokens request)
- a random UUID, if no user authenticated

fd8b5f3 introduces a regression. Post-fd8b5f3, for authenticate events only, initiator.id is the user ID in the request body, and not the authenticating user.

I believe this inconsistency is undesirable. The correct behavior should be:

- initiator is always the authenticating user (tied to the value of x-auth-token)
- target is always the "target" resource (tied to the value of the request body or request path)

This also matches the definition of INITIATOR in https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

> The RESOURCE that initiated, originated, or instigated the event's ACTION, according to the OBSERVER.

For an authenticate request where x-auth-token is not provided, the initiator value is unknown: keystone-api is not able to determine what user caused the authenticate request, because that data is not available in the request.

Similarly, TARGET:

> The RESOURCE against which the ACTION of a CADF Event Record was performed, was attempted, or is pending, according to the OBSERVER.

This would be the user specified in the request body.

[Zachary Buhman (zachary-buhman)]

I think the confusion may ultimately come from the original unit tests introduced in https://opendev.org/openstack/keystone/commit/b2b341f4700554ebe7c35307916df067cfeb61ff

Unlike "normal" unauthenticated /auth/tokens requests, these unit tests are authenticated. This causes initiator.id to have a unit-testable value, which causes "self.assertEqual(initiator.name, user_id)" to succeed in those tests.

This succeeds because, coincidentally, the user ID in the authentication request matches the authenticating user ID.

This was not mentioned https://bugs.launchpad.net/keystone/+bug/1780503 , so I suspect the author may not have been aware of this detail.

[Gage Hugo (gagehugo)]

The change and bug you linked were due to being unable to track users across openstack because all initiator.ids were just random uuids. This was observed in a deployment using LDAP backed users, it was impossible to track when users were authenticating and what they were doing, which is a huge issue when trying to audit.

> fd8b5f3 introduces a regression. Post-fd8b5f3, for authenticate events only, initiator.id is the user ID in the request body, and not the authenticating user.

The initiator has the user_id of the authenticating user, I am not sure what you mean here. Prior to the change it did not have the user id of the authenticating user, it was a random uuid.

Is there another scenario here that isn't quite working as expected?

[Zachary Buhman (zachary-buhman)]

> The change and bug you linked were due to being unable to track users across openstack because all initiator.ids were just random uuids

The 1780503 description wasn't quite accurate. pre-fd8b5f3 all Keystone APIs, including /auth/tokens, the behavior was that initiator.id is random if x-auth-token is not present, and is non-random if it is present.

I referenced 1780503 because this seems to be where the semantics of "initiator" in Keystone changed, but because this semantics change isn't explicitly called out in the bug, I suspect this semantics change is not intentional.

My specific suggestion is that we reconsider/revert the semantics change.

1780503 instead would be implemented differently: the user in the request body would be logged as target.id instead.