mohammadjkhan commented on issue #6972: Support LDAP authentication/authorization URL: https://github.com/apache/incubator-druid/pull/6972#issuecomment-482270756 @jon-wei * LDAP is supposed to be source of truth for users/groups and not roles/permissions. The standard way to implement LDAP is to manage roles and permissions at the application/framework level as rules for managing roles/permissions can (and most likely will) be different from one application to another within an enterprise, and so they aren't managed within LDAP. Also, they are not 1:1. So it's normal/common to have a mix model of where some information is kept/managed at the application level and some information is stored in LDAP * The basic authenticator shares logic related to how basic auth credentials are retrieved from the http request; how those credentials are authenticated can be different, and the CredentialsValidator interface now provides a way support for more ways of validating basic auth credentials down the road. As described in our proposal the current basic security extension limits clients to use druid internal metadata store for authentication, and one of the goals/proposals is to refactor basic security extension authenticator to make it a bit more pluggable/configurable as to how to validate requests with basic authentication credentials. Moving in to separate contrib extension will result in duplication of logic related to how basic auth credentials are processed from the http request. * How druid authorizes a user in a basic auth credential request can be managed the same way regardless of how they got authenticated (db, ldap, etc). Basically, they differ in authentication methods, but not authorization. Also, it provides a way to reuse roles/permissions. For instance, an admin user and a user belonging to an admin group can be mapped to same role in the metastore. So, it makes sense to share the role definitions * If LDAP implementations evolve over time, the changes will be only limited to LDAPCredentialsValidator in how we interact with ldap and authenticate the user. How we retrieve/process basic auth credentails from the http request and authorize the user should stay the same. I think the druid basic auth security module as a whole will be evolved over time to support more ways of authenticating HTTP Basic Authentication requests, not just against db or ldap. How Spring security has achieved that is a really good example. * Some of the design decisions were adopted to preserve backward compatibility and not introduce any breaking changes. Leaving the BasicHTTPAuthenticator mostly as is to continue leveraging and make use of the "basic" json type name and introduced CredentialsValidator as a way authenticate a basic auth credential request either against db or ldap, default is db
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
