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

Adding authentication information to access token create APIs #62490

Merged
merged 7 commits into from
Oct 16, 2020

Conversation

BigPandaToo
Copy link
Contributor

Adding authentication object to following APIs:
/_security/oauth2/token
/_security/delegate_pki
/_security/saml/authenticate
/_security/oidc/authenticate

Resolves: #59685

@BigPandaToo BigPandaToo added :Security/Client Security in clients (Transport, Rest) >enhancement Team:Security Meta label for security team v7.10.0 v8.0.0 labels Sep 17, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (:Security/Client)

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

The changes are in the right direction. A few general things can be improved upon:

  • Tests

    • For existing tests that use the updated response classes, we should use actual authentication object to fill the new field instead of null. I commented it for DelegatePkiAuthenticationResponseTests, but there are a few more places like it.
    • The YAML test failures are genuine. Those tests try to match the response object literally. The fix should be along the line of adding the authentication field into the response samples.
    • Tests for TransportXxxAction classes. This could get a bit tricky because there are not many unit tests for these type of classes. So you'll need add to the following integration tests. The following is a rough list for where some assertions could be added:
      • OpenIdConnectAuthIT#completeAuthentication
      • SamlAuthenticationIT#submitSamlResponse
      • TokenAuthIntegTests
      • PkiAuthDelegationIntegTests
  • Client code - Many of the Request and Response classes have their correspondences in the High Level Rest Client (HLRC) package, e.g. For DelegatePkiAuthenticationResponse, there is one in the org.elasticsearch.client.security package, which is different from the one in org.elasticsearch.xpack.core.security.action. They also need to be updated with the new fields. Naturally, the relevant tests also need to be updated after the main code changes.

  • New field and BackWards Compatibility (BWC) - When fields are added or removed from existing entitiy classes, extra handling are mostly (if not always) needed to ensure things work correctly in a mixed-version cluster environment. The most common changes are with the Reader and Writer interfaces, where the field is handled differently based on the in/out stream version. An example of this can be seen in SamlAuthenticateResponse, which is one of the class you need update as well.

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

1 similar comment
@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

Fixed tests, added changes to RHL APIs + test, backward compatibility, updated TransportRefreshTokenAction

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

Thanks @BigPandaToo The latest changes are looking great. This PR is turning out to be of decent size because of heavy involvement of the request/response objects. There is only one thing from my previous comment still needs to be addressed: "Tests for TransportXxxAction classes". What needs to be done is essentially adding assertions into the existing test methods that perform token related authentication to assert that the response does contain the new authentication field.

I also left a few other comments.

@andreidan andreidan added v7.11.0 and removed v7.10.0 labels Oct 7, 2020
@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

2 similar comments
@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine update branch

@BigPandaToo
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging-sample-windows

1 similar comment
@BigPandaToo
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/packaging-sample-windows

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

Thanks for the iteration. It's looking good. One of my initial comments still needs to be addressed. I am copying/pasting it here for your convenience:


  • Tests for TransportXxxAction classes. This could get a bit tricky because there are not many unit tests for these type of classes. So you'll need add them to the following integration tests. The following is a rough list for where some assertions could be added:
    • OpenIdConnectAuthIT#completeAuthentication
    • SamlAuthenticationIT#submitSamlResponse
    • TokenAuthIntegTests
    • PkiAuthDelegationIntegTests

Other than the above, I have a few other minor comments.

Adding authentication object to following APIs:
/_security/oauth2/token
/_security/delegate_pki
/_security/saml/authenticate
/_security/oidc/authenticate

Resolves: elastic#59685
(cherry picked from commit 51dbd9e)
@BigPandaToo
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/2

@BigPandaToo
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

LGTM pending on resolving following comments. Please note some of the comments are applicable to multiple places. I didn't comment on all the places to avoid duplication.

Thanks for the iterations!

@@ -104,6 +104,7 @@ public void testTokenServiceBootstrapOnNodeJoin() throws Exception {
PlainActionFuture<UserToken> userTokenFuture = new PlainActionFuture<>();
tokenService.decodeToken(response.getAccessToken(), userTokenFuture);
assertNotNull(userTokenFuture.actionGet());
assertNotNull(response.getAuthenticationResponse());
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I think this assertion is better to be close to where the response object is defined, i.e. straight after CreateTokenResponse response = restClient.... It reads better this way since the test is close to the target. Also, in case it fails, it fails quickly before having to go through the token decrpytion which involves cluster traffic.

@@ -133,6 +134,7 @@ public void testTokenServiceCanRotateKeys() throws Exception {
assertNotNull(userTokenFuture.actionGet());
assertNotEquals(activeKeyHash, tokenService.getActiveKeyHash());
}
assertNotNull(response.getAuthenticationResponse());
Copy link
Member

Choose a reason for hiding this comment

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

We should assert the authentication object's principal name as well. This is because the token creation call involves two credentials, one is the invoking user and the other is the user whom the token is created for. We can assert that the authentication's principal is the second user, not the first one.

builder.field("access_token", response.getAccessTokenString());
builder.field("refresh_token", response.getRefreshTokenString());
builder.field("expires_in", response.getExpiresIn().seconds());
builder.field("authentication", response.getAuthentication());
Copy link
Member

Choose a reason for hiding this comment

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

I wonder whether we should have null check here as well similar to how it is done in the toXContent, writeTo methods. It may not be absolutely necessary since this is a rest action and odic cannot be perform with transport client only. But then I am not sure whether there could be some weird combination that could lead to a null value here. Overall I'd say it is easier to just add a null check here so we are sure it is covered in any cases.

builder.field("access_token", response.getTokenString());
builder.field("refresh_token", response.getRefreshToken());
builder.field("expires_in", response.getExpiresIn().seconds());
builder.field("authentication", response.getAuthentication());
Copy link
Member

Choose a reason for hiding this comment

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

Same here as above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in #63792

@BigPandaToo BigPandaToo merged commit 2351bb3 into elastic:master Oct 16, 2020
@jkakavas
Copy link
Member

Heya @BigPandaToo , I think you missed some of the comments from @ywangd in the last review round! We can either revert and redo this or handle in a followup, before backporting the changes to 7.x ?

@BigPandaToo
Copy link
Contributor Author

Yep, sorry about that, already working on follow up

BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
BigPandaToo added a commit that referenced this pull request Oct 16, 2020
* Nit fixes and formatting following #62490 comments

Resolves: #63792

* Nit fixes and formatting following #62490 comments

Resolves: #63792

* Nit fixes and formatting following #62490 comments
Fixing username

* Nit fixes and formatting following #62490 comments
Fixing formatting
BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
…c#62490)

* Adding authentication information to access token create APIs

Adding authentication object to following APIs:
/_security/oauth2/token
/_security/delegate_pki
/_security/saml/authenticate
/_security/oidc/authenticate

Resolves: elastic#59685
(cherry picked from commit 51dbd9e)

* Addressing PR commends, fixing tests

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Addressing PR comments

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Update version check

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Update version check

* Addressing more PR comments

* Adding more to integration tests + some small fixes
BigPandaToo added a commit to BigPandaToo/elasticsearch that referenced this pull request Oct 16, 2020
)

* Nit fixes and formatting following elastic#62490 comments

Resolves: elastic#63792

* Nit fixes and formatting following elastic#62490 comments

Resolves: elastic#63792

* Nit fixes and formatting following elastic#62490 comments
Fixing username

* Nit fixes and formatting following elastic#62490 comments
Fixing formatting
BigPandaToo added a commit that referenced this pull request Oct 16, 2020
#63841)

* Adding authentication information to access token create APIs (#62490)

* Adding authentication information to access token create APIs

Adding authentication object to following APIs:
/_security/oauth2/token
/_security/delegate_pki
/_security/saml/authenticate
/_security/oidc/authenticate

Resolves: #59685
(cherry picked from commit 51dbd9e)

* Addressing PR commends, fixing tests

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Addressing PR comments

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Update version check

* Returning tokenGroups attribute as SID string instead of byte array (AD metadata)

Update version check

* Addressing more PR comments

* Adding more to integration tests + some small fixes

* Nit fixes and formatting following #62490 comments (#63797)

* Nit fixes and formatting following #62490 comments

Resolves: #63792

* Nit fixes and formatting following #62490 comments

Resolves: #63792

* Nit fixes and formatting following #62490 comments
Fixing username

* Nit fixes and formatting following #62490 comments
Fixing formatting

* Fixing merge conflicts

* Fixing merge conflicts
@BigPandaToo BigPandaToo deleted the APIresponse branch April 19, 2021 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Client Security in clients (Transport, Rest) Team:Security Meta label for security team v7.11.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can API operations that create access tokens include respective full user info in the response?
6 participants