-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Allow custom realms to use additional supporting objects #48369
Labels
>enhancement
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
Comments
tvernum
added
>enhancement
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
team-discuss
labels
Oct 23, 2019
Pinging @elastic/es-security (:Security/Authentication) |
We agreed that this is something we want to do. We will need to investigate a little further to determine exactly which objects should be made available. |
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
Dec 31, 2019
Previously custom realms were limited in what services and components they had easy access to. It was possible to work around this because a security extension is packaged within a Plugin, so there were ways to store this components in static/SetOnce variables and access them from the realm, but those techniques were fragile, undocumented and difficult to discover. This change includes key services as an argument to most of the methods on SecurityExtension so that custom realm / role provider authors can have easy access to them. Resolves: elastic#48369
tvernum
added a commit
that referenced
this issue
Jan 14, 2020
Previously custom realms were limited in what services and components they had easy access to. It was possible to work around this because a security extension is packaged within a Plugin, so there were ways to store this components in static/SetOnce variables and access them from the realm, but those techniques were fragile, undocumented and difficult to discover. This change includes key services as an argument to most of the methods on SecurityExtension so that custom realm / role provider authors can have easy access to them. Resolves: #48369
SivagurunathanV
pushed a commit
to SivagurunathanV/elasticsearch
that referenced
this issue
Jan 23, 2020
Previously custom realms were limited in what services and components they had easy access to. It was possible to work around this because a security extension is packaged within a Plugin, so there were ways to store this components in static/SetOnce variables and access them from the realm, but those techniques were fragile, undocumented and difficult to discover. This change includes key services as an argument to most of the methods on SecurityExtension so that custom realm / role provider authors can have easy access to them. Resolves: elastic#48369
This was referenced Feb 3, 2020
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)
Currently a
SecurityExtension
that provides a custom realm must fit into the following limitations:Realm.Factory
instances, using only a ResourceWatcherServiceRealmConfig
object onlyThat means that the only supporting objects that a realm can easily depend on are:
If it wants anything else, it needs to get acces via the
Plugin
API.Things that custom-realm-authors have said that they would like to have access to include:
Client
(which they can get fromPlugin.createComponents
, but then need to save somewhere so the realm can access it)NativeRoleMappingStore
(as aUserRoleMapper
, which can be retrieved from Guice, but that's something we're actively working to remove).The text was updated successfully, but these errors were encountered: