enhance notification for user events with user name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack Identity (keystone) |
Wishlist
|
Unassigned |
Bug Description
Is it possible to enhance the notifications for the resource_type user with user name?
Changed in keystone: | |
status: | New → Invalid |
status: | Invalid → New |
Lance Bragstad (lbragstad) wrote : | #1 |
Dmitri (dmitri-voronov) wrote : | #2 |
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.
Dmitri (dmitri-voronov) wrote : | #3 |
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:/
Changed in keystone: | |
assignee: | nobody → Lance Bragstad (lbragstad) |
status: | New → In Progress |
Dmitri (dmitri-voronov) wrote : | #5 |
Hi Lance,
great! Thanks a lot!
Regards
Dmitri
Changed in keystone: | |
importance: | Undecided → Wishlist |
Lance Bragstad (lbragstad) wrote : | #6 |
Dmitri,
Are you available on IRC at all? I have a few questions about including usernames in the audit information.
Thanks!
irc: lbragstad
Lance Bragstad (lbragstad) wrote : | #7 |
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.
Dolph Mathews (dolph) wrote : | #8 |
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.
Guang Yee (guang-yee) wrote : | #9 |
Just to be clear, we are talking about these three notifications.
keystone/
keystone/
keystone/
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-
I would favor adding username + domain for now, till we have a complete resource lifecycle management framework in place.
David Stanek (dstanek) wrote : | #10 |
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.
Guang Yee (guang-yee) wrote : | #11 |
Oh sure. When receiving a "deleted" event, customers can always roll their nightly tape backup to lookup that user. No biggie. :-)
Lance Bragstad (lbragstad) wrote : | #12 |
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?
Dmitri (dmitri-voronov) wrote : | #13 |
I agree with the comment https:/
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:/
Dmitri (dmitri-voronov) wrote : RE: [Bug 1552795] Re: enhance notification for user events with user name | #14 |
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:/
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:/
Lance Bragstad (lbragstad) wrote : | #15 |
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.
Changed in keystone: | |
assignee: | Lance Bragstad (lbragstad) → nobody |
Steve Martinelli (stevemar) wrote : | #16 |
Patch https:/
Dmitri (dmitri-voronov) wrote : | #17 |
Sorry, what does it mean?
Lance Bragstad (lbragstad) wrote : | #18 |
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:/
Reason: Abandoning this for now.
Changed in keystone: | |
status: | In Progress → Triaged |
Hi Dmitri,
What's the reasoning behind having the username versus having the globally unique user ID?