-
Notifications
You must be signed in to change notification settings - Fork 24.6k
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
Add the capability for the LDAP and AD realms to bind using Kerberos credentials #41126
Changes from 15 commits
cd80858
42ff127
230bc87
33dbb09
d3be59f
20cbecd
e29cf26
7332792
26ae7da
955469e
b2b4963
841f394
eaa5965
e6eda93
d9e5293
23bfb73
0ee24b1
1119857
986ff5e
7a5dc4c
b6dba5d
6fbf757
460b8aa
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,7 +9,24 @@ grant { | |
permission java.util.PropertyPermission "*", "read,write"; | ||
|
||
// needed for multiple server implementations used in tests | ||
permission java.net.SocketPermission "*", "accept,connect"; | ||
permission java.net.SocketPermission "*", "accept,connect,resolve"; | ||
|
||
// needed for GSSAPI bind to LDAP | ||
permission javax.security.auth.AuthPermission "modifyPrincipals"; | ||
permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; | ||
permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosKey * \"*\"", "read"; | ||
permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KeyTab * \"*\"", "read"; | ||
permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.kerberos.KerberosTicket * \"*\"", "read"; | ||
permission javax.security.auth.AuthPermission "doAs"; | ||
permission javax.security.auth.kerberos.ServicePermission "*","initiate,accept"; | ||
|
||
permission java.util.PropertyPermission "javax.security.auth.useSubjectCredsOnly","write"; | ||
permission java.util.PropertyPermission "java.security.krb5.conf","write"; | ||
permission java.util.PropertyPermission "sun.security.krb5.debug","write"; | ||
permission java.util.PropertyPermission "java.security.debug","write"; | ||
|
||
permission javax.security.auth.AuthPermission "createLoginContext.GSSAPIBindRequest"; | ||
permission javax.security.auth.AuthPermission "setLoginConfiguration"; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can't these be moved to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, as unboundid dependencies are in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think these are a lot of obscure permissions we're granting for any plugin (that inherits What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ++ on moving the dependencies and getting the permissions in one place, though I see a TODO which I think is a non-trivial change and would require considerable thought as I am not much aware of what needs to be done here. I think I will pick this up later as a cleanup task. Thank you. |
||
}; | ||
|
||
grant codeBase "${codebase.netty-common}" { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the switch validation !
But, can't we infer the mode from if
SASL_GSSAPI_PRINCIPAL
is present.SASL_GSSAPI_PRINCIPAL
cannot benull
in the way we use the library, right? Also, usingSASL_GSSAPI_PRINCIPAL
together with aBIND_DN
should trigger a settings validation error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now other than
simple
andsasl_gssapi
we do not wish to support other bind types but there are other bind types via SASL that the LDAP has support for. So relying on the presence ofSASL_GSSAPI_PRINCIPAL
orSASL_GSSAPI_KEYTAB_PATH
is something I would like to avoid.Right now it gets ignored but I agree to throw settings validation error in presence of both
BIND_DN
andSASL_GSSAPI_PRINCIPAL
settings. I will make these changes. Thank you.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't other bind methods not also have their setting keys namespaced similarly to
sasl_gssapi
? So there would be no ambiguity? To me this is a case of namespaced settings versus conditional settings, as in #30241 . The conditional setting is harder to validate in the code, compared to the namespaced ones, because the validation of the namespaced ones is just to get the whole namespace and validate them as a group. It's also simpler from a user perspective, because he has fewer settings to worry about.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just an opinion, do as you think, or ask for other's opinions.