OpenStack Identity (keystone)

"initiator" in authenticate CADF notifications has an inconsistent meaning

Bug #1925239 reported by Zachary Buhman
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
New
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Zachary Buhman (zachary-buhman) wrote :

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.

Revision history for this message
Gage Hugo (gagehugo) wrote :

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?

Revision history for this message
Zachary Buhman (zachary-buhman) wrote :

> 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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.