← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1925239] [NEW] "initiator" in authenticate CADF notifications has an inconsistent meaning

 

Public bug reported:

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.

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1925239

Title:
  "initiator" in authenticate CADF notifications has an inconsistent
  meaning

Status in OpenStack Identity (keystone):
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1925239/+subscriptions