-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add authentication sub-namespace to user #1146
Conversation
I would suggest we look to finalise the discussion in #1104 especially around scenarios & use cases prior to merging this request. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
please keep open. |
@AlexanderWert can you please join next Monday's semcon SIG to discuss this? I will be there. |
please update also markdown |
@AlexanderWert could you please take another look? I believe your feedback was addressed. |
- ref: enduser.role | ||
- ref: user.id | ||
requirement_level: | ||
conditionally_required: If instrumentation supports tracking unauthenticated users and if `user.authentication.id` is set, recommended otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I think I got it wrong in my previous suggestion.
We don't want user.id
to be used for authenticated users, do we? so I guess it should be
conditionally_required: If instrumentation supports tracking unauthenticated users and if `user.authentication.id` is set, recommended otherwise. | |
conditionally_required: If and only if instrumentation supports tracking unauthenticated users. |
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the goal is to prevent someone from duplicating things (or using user.id for authenticated one) like
❌ Bad:
user.authentication.id = lmolkova
user.id = lmolkova
❌ Bad:
user.id = lmolkova
we want people to do
✅ Good:
user.id = QdH5CAWJgqVT4rOr0qtumf
✅ Good:
user.id = QdH5CAWJgqVT4rOr0qtumf
user.authentication.id = lmolkova
✅ Good:
user.authentication.id = lmolkova
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe another way to same this is that this value SHOULD NOT be identifying in anyway to the real user id. So this value MUST not contain PII which can directly identify the authenticated user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PII is once concern, but my main point is is avoid duplication (you should not generate new guid for the sake of populating user.id) and consistency - everyone should be using user.*.id
in the same way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for azure monitor javascript SDK, browser always has a cookie named ai_user=QdH5CAWJgqVT4rOr0qtumf
.
this will be tracked via user.id
regardless of whether user is authenticated or not. user can choose to use user.authentication.id
for the real user's id/name.
can we make it not required and remove the condition completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm missing something.
The condition here is if tracking unauthenticated users is supported, so azmon distro should set user.id
based on it.
this condition says nothing about authentication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all i'm saying that user.id
is not a required field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would this work?
conditionally_required: If instrumentation supports tracking unauthenticated users and if `user.authentication.id` is set, recommended otherwise. | |
recommended: If and only if instrumentation supports tracking unauthenticated users. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm saying that user.id is not a required field.
It might be not required for this specific use case. But for anything related to the users in OS user.id
is well known and important field
model/registry/user.yaml
Outdated
The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. | ||
In browser scenarios `user.id` is usually stored in cookies. | ||
|
||
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. | ||
|
||
It can be a random guid or a hash of the user's IP address. This is different from `user.hash` which is a hash of a known `user.id` or `user.name`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, one more minor suggestion to rearrange things slightly (feel free to rephrase or not take it at all)
The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. | |
In browser scenarios `user.id` is usually stored in cookies. | |
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. | |
It can be a random guid or a hash of the user's IP address. This is different from `user.hash` which is a hash of a known `user.id` or `user.name`. | |
The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. | |
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. | |
In browser scenarios `user.id` is usually stored in cookies. It can also be a random guid or a hash of the user's IP address. This is different from `user.hash` which is a hash of a known `user.authentication.id` or `user.name`. |
**[2]:** Useful if `user.authentication.id` or `user.name` contain confidential information and cannot be used. | ||
|
||
**[3]:** The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. In browser scenarios `user.id` is usually stored in cookies. | ||
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove this line, OpenTelemetry should not be making these statement.
As it's up to the application to determine whether or not they want to track the user.id when the user in authenticated. For client applications this is almost ALWAYS required as they will use this to identify the "user" in some random way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
we want authenticated user id to always be in the same attribute user.authentication.id
. If you don't have means to track unauthenticated users, you should never populate user.id
.
Otherwise how you see people using those attributes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only authenticated user id can be tracked through user.authentication.id
and everything else is tracked through 'user.id', it can be anonymous, random, pseudo, unauthenticated, unauthorized and etc. can we not make any recommendation how OpenTelemetry customers use this attribute? as long as we have a crystal-clear description, it's up to the users to decide. does it help?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're recommending to use user.id
only if app has some means to identify them (without authentication),
Assuming app has no means to identify users before authentication, user.id
should not be used.
App can identify them by generating guid on every call, that's also a way of identification/tracking.
So from what I can tell this NOT RECOMMENDED
just reinforces the description and does not contradict anything you're saying.
I want to keep this sentence since I expect people to put things they don't need into user.id
and want to do as much as possible to avoid it. What's the problem in keeping it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion on this; your argument seems valid. let's try to resolve it in Monday's SIG with @MSNev and everyone else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m finding these names a bit confusing, and agree with this:
I expect people to put things they don't need into
user.id
and want to do as much as possible to avoid it
It seems that unauthenticated/tracking/pseudo user ids are fairly specific to client (browser/mobile) instrumentation, so maybe it’s better to have a more specific name for that concept (and not use user.id
for it)?
| [`user.roles`](/docs/attributes-registry/user.md) | string[] | Array of user roles at the time of the event. | `["admin", "reporting_user"]` | `Recommended` | ![Experimental](https://img.shields.io/badge/-experimental-blue) | | ||
|
||
**[1]:** The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. In browser scenarios `user.id` is usually stored in cookies. | ||
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again remove
The `user.id`, when populated, is expected to be generated before user is authenticated and SHOULD NOT change after the user logs in. | ||
In browser scenarios `user.id` is usually stored in cookies. | ||
|
||
It's NOT RECOMMENDED to populate this attribute when unauthenticated users are not tracked or identified by the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see comments about being not recommended.
@heyams hey, do you have any updates for this issue? Can you ping me in slack if you have worked on it while I was away? |
will do |
Do we want to close this one in favor of #1456? |
Fix #1104
I chose
user.anonymous_id
because of #1121