Skip to content

Conversation

@ywangd
Copy link
Member

@ywangd ywangd commented Mar 23, 2022

This PR removes the AuthenticationContext class introduced in #80926 and
merges its functions into Authentication.

It becomes more apparent that the most useful refactoring in #80926 is
the new Subject class, which is also what AuthenticationContext provides
most of its value. The AuthenticationContext is essentially just a thin
wrapper of two subjects which represents the existing Authentication
object in a more structured format. The original plan was to replace
Authentication with AuthenticationContext. However, it has practical
challenges that the usage of Authentication is too wide spread. It's
hard to have a series of scoped changes to replace it. Therefore the new
plan is to stick with Authentication, agumenting it with subjects
similar to what AuthenticationContext has and remove
AuthenticationContext. This PR also deprecates methods that should be
replaced by methods of Subjects. In future, the plan is to remove the
deprecated methods, also rework the User class so it does not need
nest another User to represent run-as (which is another main reason for
the original refactor #80926). Overall, the new plan makes it easier to
spread the work in a few more tightly scoped PRs while achieving the
same original goal.

This PR removes the AuthenticationContext class introduced in elastic#80926 and
merges its functions into Authentication.

It becomes more apparent that the most useful refactoring in elastic#80926 is
the new Subject class, which is also what AuthenticationContext provides
most of its value. The AuthenticationContext is essentially just a thin
wrapper of two subjects which represents the existing Authentication
object in a more structured format. The original plan was to replace
Authentication with AuthenticationContext. However, it has practical
challenges that the usage of Authentication is too wide spread. It's
hard to have a series of scoped changes to replace it. Therefore the new
plan is to stick with Authentication, agumenting it with subjects
similar to what AuthenticationContext has and remove
AuthenticationContext. This PR also deprecates methods that should be
replaced by methods of Subjects. In future, the plan is to remove the
deprecated methods, also rework the User class so it does not need
nest another User to represent run-as (which is another main reason for
the original refactor elastic#80926). Overall, the new plan makes it easier to
spread the work in a few more tightly scoped PRs while achieving the
same original goal.
@ywangd ywangd added >refactoring :Security/Security Security issues without another label v8.2.0 labels Mar 23, 2022
@ywangd ywangd requested a review from tvernum March 23, 2022 06:38
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Mar 23, 2022
@elasticmachine
Copy link
Collaborator

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

} else {
authenticatingSubject = effectiveSubject = new Subject(user, authenticatedBy, version, metadata);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we sure this method doesn't need to be thread-safe (because it's not).

Copy link
Member Author

Choose a reason for hiding this comment

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

On a second thought, this method needs to be thread-safe because it's setting two variables so inherently not atomic.

Taking a step back, I was trying to save some computation by delay the initialising the subjects. But I think the save here is too marginal. Introducing a synchornisation is likely to defeat the purpose. So I just inlined it into the constructors.

@ywangd ywangd force-pushed the remove-authentication-context branch from a278de5 to 6ec1809 Compare April 26, 2022 05:57
@ywangd ywangd requested a review from tvernum April 26, 2022 05:58
@ywangd ywangd merged commit 7a3dd5a into elastic:master Apr 26, 2022
ywangd added a commit to ywangd/elasticsearch that referenced this pull request Apr 26, 2022
In elastic#85255, some mocking of Authentication class got replaced by randomly
creating actual Authentication objects. This is a general direction we
want to head towards because Authentication object has plenty internal
logics which makes it hard to mock correctly (and also undesirable). The
recent change in elastic#85590 adds a test helper which makes randomising
Authentication object easier for tests.

For ApiKeyServiceTests.testGetApiKeyMetadata, the randomisation is
however too broad (broader then what the mocking provided) and can
sometimes creates authentication object that does not pass the
assertion.

The assertion expects no API key authentication. But the randomisation
can generate such one because it randomises whether the authentication
has run-as even when the effective user is from a realm. Since API keys
can run-as, the resulted Authentication object can be an overall API key
authentication object.

This PR reduces the randomness by not allow run-as so that the resulted
Authentication cannot be API keys.

Relates: elastic#85255
Resolves: elastic#86179
ywangd added a commit that referenced this pull request Apr 26, 2022
In #85255, some mocking of Authentication class got replaced by randomly
creating actual Authentication objects. This is a general direction we
want to head towards because Authentication object has plenty internal
logics which makes it hard to mock correctly (and also undesirable). The
recent change in #85590 adds a test helper which makes randomising
Authentication object easier for tests.

For ApiKeyServiceTests.testGetApiKeyMetadata, the randomisation is
however too broad (broader then what the mocking provided) and can
sometimes creates authentication object that does not pass the
assertion.

The assertion expects no API key authentication. But the randomisation
can generate such one because it randomises whether the authentication
has run-as even when the effective user is from a realm. Since API keys
can run-as, the resulted Authentication object can be an overall API key
authentication object.

This PR reduces the randomness by not allow run-as so that the resulted
Authentication cannot be API keys.

Relates: #85255
Resolves: #86179
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>refactoring :Security/Security Security issues without another label Team:Security Meta label for security team v8.3.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants