Skip to content
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

Closed
wants to merge 22 commits into from

Conversation

heyams
Copy link
Contributor

@heyams heyams commented Jun 11, 2024

Fix #1104

I chose user.anonymous_id because of #1121

@heyams heyams requested review from a team June 11, 2024 23:31
model/registry/user.yaml Outdated Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
@thompson-tomo
Copy link

I would suggest we look to finalise the discussion in #1104 especially around scenarios & use cases prior to merging this request.

Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Jun 29, 2024
@heyams
Copy link
Contributor Author

heyams commented Jul 1, 2024

This PR was marked stale due to lack of activity. It will be closed in 7 days.

please keep open.

@lmolkova lmolkova removed the Stale label Jul 2, 2024
@heyams
Copy link
Contributor Author

heyams commented Jul 2, 2024

@AlexanderWert can you please join next Monday's semcon SIG to discuss this? I will be there.

@trisch-me trisch-me added the never stale PRs marked with this label will be never staled and automatically closed label Jul 16, 2024
model/registry/user.yaml Outdated Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
Co-authored-by: Alexandra Konrad <alexandra.konrad@elastic.co>
@trisch-me
Copy link
Contributor

please update also markdown

@heyams heyams requested a review from a team July 22, 2024 15:30
@trisch-me
Copy link
Contributor

@heyams let's wait for outcome of the discussion in the related issue
#1104 before continuing on this PR

model/registry/user.yaml Outdated Show resolved Hide resolved
@heyams
Copy link
Contributor Author

heyams commented Aug 6, 2024

i can't validate chlolg yaml locally.. stuck with this

image

@heyams heyams changed the title Add anonymous_id to user namespace Add authentication sub-namespace to user Aug 6, 2024
.chloggen/add_authentication_user_subnamespace.yaml Outdated Show resolved Hide resolved
model/general.yaml Outdated Show resolved Hide resolved
model/general.yaml Outdated Show resolved Hide resolved
model/general.yaml Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
model/registry/user.yaml Outdated Show resolved Hide resolved
.chloggen/add_authentication_user_subnamespace.yaml Outdated Show resolved Hide resolved
docs/attributes-registry/user.md Outdated Show resolved Hide resolved
docs/attributes-registry/user.md Outdated Show resolved Hide resolved
@lmolkova
Copy link
Contributor

lmolkova commented Aug 8, 2024

@AlexanderWert could you please take another look? I believe your feedback was addressed.

@heyams
Copy link
Contributor Author

heyams commented Aug 8, 2024

image

i checked that link is still live. is this false negative?

- 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.
Copy link
Contributor

@lmolkova lmolkova Aug 8, 2024

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

Suggested change
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?

Copy link
Contributor

@lmolkova lmolkova Aug 8, 2024

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

Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

@heyams heyams Aug 8, 2024

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?

Copy link
Contributor

@lmolkova lmolkova Aug 8, 2024

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.

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would this work?

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

Copy link
Contributor

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

Comment on lines 33 to 38
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`.
Copy link
Contributor

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)

Suggested change
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.
Copy link
Contributor

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

Copy link
Contributor

@lmolkova lmolkova Aug 8, 2024

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?

Copy link
Contributor Author

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?

Copy link
Contributor

@lmolkova lmolkova Aug 9, 2024

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?

Copy link
Contributor Author

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.

Copy link
Member

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.
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove

Copy link
Contributor

@MSNev MSNev left a 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.

@trisch-me
Copy link
Contributor

@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?

@heyams
Copy link
Contributor Author

heyams commented Sep 16, 2024

@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

@lmolkova
Copy link
Contributor

Do we want to close this one in favor of #1456?

@heyams heyams closed this Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:security never stale PRs marked with this label will be never staled and automatically closed
Projects
Status: Done
Archived in project
Development

Successfully merging this pull request may close these issues.

User.id for authenticated user id