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

Authentication under domains #82639

Merged

Conversation

albertzaharovits
Copy link
Contributor

@albertzaharovits albertzaharovits commented Jan 15, 2022

This makes the ubiquitous Authentication object contain the domain information that will later be used for access control decisions related to ownership.
The domain information is a Set of RealmIdentifiers of the authentication realms configured under the same domain name.

@albertzaharovits albertzaharovits added >feature :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) v8.1.0 labels Jan 15, 2022
@albertzaharovits albertzaharovits self-assigned this Jan 15, 2022
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.

I scanned through the code and didn't read too closely. I have an overall "design" question:

What do you think if we attach all domain information to RealmRef instead of split them between RealmRef and Authentication? I am also thinking promoting Domain into it's own class. So it's something like:

public record Domain(String name, Set<RealmRef> realmRefs) {}

public class RealmRef {
  String name;
  String type;
  String nodeName;
  @Nullable Domain domain;
}

One advantage of this approach is that we can keep all domain information for both authenticatedBy and lookupBy realms. It is also more expandable if we decide to keep delegate realm info in the future as well. Semantically, domain is also more akin to realm. Another advantage is that it requires no cascading changes to AuthenticationContext.

@elasticsearchmachine
Copy link
Collaborator

Hi @albertzaharovits, I've created a changelog YAML for you.

@albertzaharovits
Copy link
Contributor Author

albertzaharovits commented Jan 26, 2022

What do you think if we attach all domain information to RealmRef instead of split them between RealmRef and Authentication? I am also thinking promoting Domain into it's own class.

We discussed it on another channel, and I agreed that it is a good suggestion that I will follow.

@albertzaharovits albertzaharovits force-pushed the authentication-under-domains branch from 3d28f78 to e6bb998 Compare January 27, 2022 21:19
@elasticsearchmachine
Copy link
Collaborator

Hi @albertzaharovits, I've created a changelog YAML for you.

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.

This is looking great! Thanks for the iterations! I had quite a few comments. But none of them is critical. Also:

  • I suggest we update the PR description to replace realm ref with realm id as well.
  • Nothing really to do for this, but I'd like to double click that the equals and/or hashCode method of RealmRef (and in turn Authentication) cannot be relied upon for ownership checking because domain configuration can change independantly.

Comment on lines 511 to 512
assert authentication.isAuthenticatedInternally();
assert false == authentication.isAssignedToDomain();
Copy link
Member

Choose a reason for hiding this comment

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

Nit: Are these assertions necessary given the Authentication object is directly instantiated here?

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 would like to keep the isAssignedToDomain asserts. I like that they document which authentications are outside domains.

@albertzaharovits
Copy link
Contributor Author

Test failure https://gradle-enterprise.elastic.co/s/sqmaob7d4novq is already tracked (and muted) #83516 .

@elasticsearchmachine
Copy link
Collaborator

Hi @albertzaharovits, I've updated the changelog YAML for you.

@albertzaharovits albertzaharovits force-pushed the authentication-under-domains branch from 10d442b to aceb2f9 Compare February 4, 2022 19:04
@elasticsearchmachine
Copy link
Collaborator

Hi @albertzaharovits, I've created a changelog YAML for you.

@albertzaharovits
Copy link
Contributor Author

🎉

@albertzaharovits albertzaharovits merged commit 53adb09 into elastic:master Feb 4, 2022
@albertzaharovits
Copy link
Contributor Author

Like we discussed I'm planing to open follow-up PRs for some refactorings that were reverted by 0ebd996 .

ywangd added a commit to ywangd/elasticsearch that referenced this pull request Feb 22, 2022
This PR removes conditional check for metadata keys related to API key
role descriptors. API key authentication must always have these keys for
it to work. The PR adds assertions for these keys and fixes relevant
tests.

Relates: elastic#82639
ywangd added a commit that referenced this pull request Feb 24, 2022
)

This PR removes conditional check for metadata keys related to API key
role descriptors. API key authentication must always have these keys for
it to work. The PR adds assertions for these keys and fixes relevant
tests.

Relates: #82639
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team v8.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants