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

Move configuration of special realms to additionalSettings #51387

Open
tvernum opened this issue Jan 24, 2020 · 2 comments
Open

Move configuration of special realms to additionalSettings #51387

tvernum opened this issue Jan 24, 2020 · 2 comments
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team

Comments

@tvernum
Copy link
Contributor

tvernum commented Jan 24, 2020

Possibly related: #36591 #50892

At the moment we have 3 special realms for which we do extra configuration that doesn't use the global Settings object.

  • We always add a reserved realm, unless it is disabled (through an undocumented config that sitso utside the realm chain).
  • We add a native realm and a file realm if there are no other enabled realms (other than reserved).

I would like to consider moving all of that config into the Settings object, by implementing it in Security.additionalSettings().

In that method we would:

  1. If the YML settings does not include a reservered realm, add one, with order Integer.MIN_VALUE
  2. If the YML settings does not include a file realm, add one, with order Integer.MIN_VALUE + 1
  3. If the YML settings does not include a native realm, add one, with order Integer.MIN_VALUE + 2

When we consider whether the settings includes a realm, we would treat enabled: false as being an included realm, so you could explicitly disable any of those 3 realms by adding them to the YML, and setting enabled to false.

This would mean that the node's settings always reflect the actual realm chain.
It would remove the magic setting to disable the reserved realm, and cases where the reserved realm was disabled would be just like any other disabled realm.

We would probably also want to add a validation in Realms to check that the reserved realm had the lowest order, and fail if it didn't.

We'd need to think about how this might work with dynamic realm configuration, but it potentially makes it easier by making all the realm stuff be done through Settings - it would just required that dynamic node config loading and additionalSettings played nicely together.

@tvernum tvernum added :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) team-discuss labels Jan 24, 2020
@elasticmachine
Copy link
Collaborator

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

@tvernum
Copy link
Contributor Author

tvernum commented Feb 13, 2020

We agreed that this was a reasonable direction to take, but it depends on how #50892 ends up being decided.

@rjernst rjernst added the Team:Security Meta label for security team label May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team
Projects
None yet
Development

No branches or pull requests

3 participants