[API keys] Add full_name and email to API key doc and use them to populate authing User #61354
+36
−4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lloydmeta
added
>enhancement
>non-issue
:Security/Security
…ulate user The API key document currently doesn't include the user's full_name or email attributes. This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well. Signed-off-by: lloydmeta <[email protected]>
lloydmeta
force-pushed
the
security/API-keys-add-full_name-email-to-doc
branch
from
b620dff to
18fa022
Compare
Signed-off-by: lloydmeta <[email protected]>
Collaborator
|
Pinging @elastic/es-security (:Security/IdentityProvider) |
jkakavas
approved these changes
Aug 20, 2020
Contributor
jkakavas
left a comment
jkakavas
left a comment
There was a problem hiding this comment.
LGTM! Thanks LLoyd. I consider this a bug so I agree it should go in the next patch releases ( 7.8.2, 7.9.1 ) too. I don't see this breaking a client's response, the Authenticate API is supposed to be returning these two fields either way
...plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/ApiKeyServiceTests.java
Outdated
Show resolved
Hide resolved
Signed-off-by: lloydmeta <[email protected]>
lloydmeta
force-pushed
the
security/API-keys-add-full_name-email-to-doc
branch
from
135cbc0 to
a13a122
Compare
Contributor
|
@lloydmeta we usually tend to wait for a review from all reviewers that we ask. No big deal though, Tim can always comment and we can adjust if he has any suggestions/objections. I realize this is not the practice in all repos/teams ,just bringing it up for future reference:) |
Member
Author
Oh, sorry about that. Thanks for letting me know :) makes sense to me. Will keep that in mind. |
Contributor
|
I dropped @lloydmeta Do you want us to backport this, or do you have it under control? |
Member
Author
|
Thanks @tvernum I'm happy to handle the backporting as well. |
lloydmeta
added a commit
to lloydmeta/elasticsearch
that referenced
this pull request
Aug 21, 2020
…hem to populate authing User (elastic#61354) The API key document currently doesn't include the user's full_name or email attributes, and as a result, when those attributes return `null` when hitting `GET`ing `/_security/_authenticate`, and in the SAML response from the [IdP Plugin](elastic#54046). This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well. Signed-off-by: lloydmeta <[email protected]>
lloydmeta
added a commit
to lloydmeta/elasticsearch
that referenced
this pull request
Aug 21, 2020
…se them to populate authing User (elastic#61354) The API key document currently doesn't include the user's full_name or email attributes, and as a result, when those attributes return `null` when hitting `GET`ing `/_security/_authenticate`, and in the SAML response from the [IdP Plugin](elastic#54046). This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well. Signed-off-by: lloydmeta <[email protected]>
Member
Author
|
Backports:
Would appreciate a spot check from one of you to make sure I did those right before merging @jkakavas @tvernum |
lloydmeta
added a commit
that referenced
this pull request
Aug 21, 2020
…hem to populate authing User (#61354) (#61403) The API key document currently doesn't include the user's full_name or email attributes, and as a result, when those attributes return `null` when hitting `GET`ing `/_security/_authenticate`, and in the SAML response from the [IdP Plugin](#54046). This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well. Signed-off-by: lloydmeta <[email protected]>
lloydmeta
added a commit
that referenced
this pull request
Aug 21, 2020
…se them to populate authing User (#61354) (#61404) The API key document currently doesn't include the user's full_name or email attributes, and as a result, when those attributes return `null` when hitting `GET`ing `/_security/_authenticate`, and in the SAML response from the [IdP Plugin](#54046). This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well. Signed-off-by: lloydmeta <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The API key document currently doesn't include the user's full_name or email attributes, and as a result, when those attributes return
nullwhen hittingGETing/_security/_authenticate, and in the SAML response from the IdP Plugin.This changeset adds those fields to the document and extracts them to fill in the User when authenticating. They're effectively going to be a snapshot of the User from when the key was created, but this is in line with roles and metadata as well.