-
Notifications
You must be signed in to change notification settings - Fork 431
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 attested user and groups to process #2050
Conversation
schemas/user.yml
Outdated
@@ -54,6 +54,10 @@ | |||
as: real_user | |||
short_override: The real user (ruid). Identifies the real owner of the process. | |||
beta: Reusing the `user` fields in this location is currently considered beta. | |||
- at: process | |||
as: attested_user | |||
short_override: The attested user (auid). Identifies the attested used associated with the process. |
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.
Also, i know there isn't a ton of space for descriptions on nested fields. "short only", but I wonder if we can explain what attested means. e.g via 2factor mechanisms etc...
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.
"externally" attested is the key aspect ie they have done something to prove to an external source (e.g. pw & 2nd factor) that they are who claim to be and authorized to obtain the role/identity stated here.
This works good as a nested field. When this gets merged and we update endpoint-package, we'll need to decide what nesting this attested_user lives at (mapping wise). Assuming it will only be attested once at the entry_leader process, it probably makes sense to only add a mapping for process.entry_leader.attested_user and process.entry_leader.attested_group. Not only where it's nested, but which fields in the user fieldset will be mapped. e.g email, username etc... |
@mitodrummer , we're inclined to use this mapping:
|
…n is based on an external source
…roups to CHANGELOG
1fa66c1
to
e5a4e50
Compare
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.
LGTM!
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.
LGTM. Nice work & thanks @daniel-almeida.
We can review if we need to support more than one externally attested identity per event before this leaves beta.
@daniel-almeida I think these changes look good, I just have one question. Can we get these added to the subset file, or is there is a reason that was omitted? example: process.supplemental_groups |
That was probably oversight on my part, @kgeller . I'll look into 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.
LGTM
* Add attested user and group to process * Drop auid, make attested groups an array, and clarify that attestation is based on an external source * Update short description and add process.attested_user and attested_groups to CHANGELOG * subset file updated for process.entry_leader.attested_user and attested_groups * updates from make Co-authored-by: Karl Godard <[email protected]> Co-authored-by: Kylie Geller <[email protected]> # Conflicts: # experimental/generated/csv/fields.csv # generated/csv/fields.csv
make test
? N/Amake
and committed those changes? yes