enhance notification for user events with user name

Hi Dmitri,

What's the reasoning behind having the username versus having the globally unique user ID?

Hello Lance,

not all e.g. legacy systems would use the keystone ID or the same ID, but for sure the same user name. Thus getting notified is not enough and the notification consumer has to use keystone API to retrieve additional resource information, here the user name. In our solution we introduced keystone’s ID as an additional attribute, so we can map keystone’s user to those in our system. But not each legacy system allows such an extension.
In general it would increase the keystone’s usability if notifications would have also the name of the resource.

Hi Lance,

BTW another use case: auditing. It is more readable to have user names instead of IDs.

Regards
Dmitri

Fix proposed to branch: master
Review: https://review.openstack.org/288643

Hi Lance,

great! Thanks a lot!

Regards
Dmitri

Dmitri,

Are you available on IRC at all? I have a few questions about including usernames in the audit information.

Thanks!
irc: lbragstad

Dmitri,

I did a little digging as to why we only included the resource ID in the payload originally. The idea was that given a resource ID and a type, a consumer could ask keystone for more information. The information that is being asked for can vary across consumers - some might care about usernames, others might care about a different attribute. In that case, it seems best to leave that up to the consumer instead of including things that we assume they care about.

Another thing to think about is how adding usernames here will be affected by shadow users? If we include usernames, are we going to be forced to include domain IDs in the future? I could see the footprint of the notification payload growing over time.

Comment #7: +1

You'd already have to include domain IDs if you're going to include user names, because user names are not unique across domains.

In addition, federated users would need special treatment as well, as you'd have to include the IdP ID, protocol ID, and mapping ID just for the "name" to have any meaning (because it is not unique otherwise).

I'm in favor of Won't Fix.

Just to be clear, we are talking about these three notifications.

keystone/identity/core.py: notifications.Audit.created(self._USER, user['id'], initiator)
keystone/identity/core.py: notifications.Audit.updated(self._USER, user_id, initiator)
keystone/identity/core.py: notifications.Audit.deleted(self._USER, user_id, initiator)

Not authenticate. Not initiator user_id.

These are for Keystone locally managed users. Even for shadow user, this is the local copy so I don't think it will impact federated users.

Though for the deleted event, the lookup user attributes after the fact argument may not hold as user has already been deleted from the backend. Unless we want to dig it up from backend-and-recovery system or something.

I would favor adding username + domain for now, till we have a complete resource lifecycle management framework in place.

I would rather not do this. I agree with #7 and think it's a slippery slope. Someone else my want a different attribute. Or if this becomes the pattern someone will inevitably ask for attributes on other events.

I disagree with #9 on the grounds that whatever we do will have to be supported for a long, long time. I don't like band-aids like this when there is a clear workaround.

In the original bug report it is only speculated that other systems may not be as extensible as the OP. Let's wait until we have a real use case before we jump into action.

Oh sure. When receiving a "deleted" event, customers can always roll their nightly tape backup to lookup that user. No biggie. :-)

If someone really cares about auditing information are they going to rely on a system (like keystone) where things aren't persisted in a shadow table or soft deleted?

I agree with the comment https://review.openstack.org/288643: if entity has been deleted it is away, no chance to query further details. And with #9 which confirms the first. For me it sounds as a quite real use case. How to answer the question: who was this guy from domain x, who participated on project y, in the group z and did several things but now has gone?
What about extending CADF payload with additional properties or probably make its content configurable so that the customers can extend content with the properties defined by keystone schema?
As I’ve seen in this document
https://wiki.openstack.org/w/images/e/e1/Introduction_to_Cloud_Auditing_using_CADF_Event_Model_and_Taxonomy_2013-10-22.pdf there is already mentioned the idea of user ID/name pairs within CADF payload, but I think it is not available yet.

Hi Lance,

Unfortunately I have no experience with IRC but I would try it out. My nickname is dimonv.

Regards,
Dmitri

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Lance Bragstad
Sent: Dienstag, 8. März 2016 16:02
To: Voronov Dmitri
Subject: [Bug 1552795] Re: enhance notification for user events with user name

Dmitri,

Are you available on IRC at all? I have a few questions about including usernames in the audit information.

Thanks!
irc: lbragstad

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1552795

Title:
  enhance notification for user events with user name

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  Is it possible to enhance the notifications for the resource_type user
  with user name?

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

Automatically unassigning due to inactivity. This has come up a couple times in discussion. The patch in review needs to be re-evaluated based on discussions at summits and meetings.

Patch https://review.openstack.org/#/c/288643/ still applicable, needs a rebase

Sorry, what does it mean?

Dmitri,

I think what Steve means is that we should rebase the patch in comment #4 and discuss whether or not we agree with the approach as a team.

Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https://review.openstack.org/288643
Reason: Abandoning this for now.