Ok, so I plumbed a ZKDatabase into the auth plugins. I do this by adding a setter to the AuthenticationProvider interface that is called after construction so that I can use the current method to construct the AuthProviders in the ProviderRegistry. I also added a ZooKeeperServer arg to both ProviderRegistry.initialize() and ProviderRegistry.getProvider(). All the places where getProvider is called happened to have a ZooKeeperServer object available for the passing. I also added an implementation that does nothing for the setter to each of the existing plugins.
The cool thing is that I get access to the ZKDatabase object on the system. This allows me to drive auth decisions from the ZKDatabase. Would a patch for this plumbing be interesting in an of itself? wt On Tue, Jul 31, 2012 at 2:37 PM, Warren Turkal <[email protected]> wrote: > On Tue, Jul 31, 2012 at 2:02 PM, Patrick Hunt <[email protected]> wrote: > > > On Mon, Jul 30, 2012 at 11:04 AM, Warren Turkal <[email protected]> wrote: > > > I'm sure this is a really newbie type question, but I couldn't find > docs > > on > > > how to do this. > > > > > > I am researching making a pluggable auth module. Is there any way to > > access > > > data in zookeeper nodes from a pluggable auth module? I'd like to store > > the > > > auth data within a collection of zookeeper nodes. > > > > > > > We don't provide for this. Wouldn't you need auth for those znodes in > > order to provide auth? Seems like a circular problem... > > > > The auth can be overridden by other methods just like normally can happen > so the auth for these nodes could come from the digest scheme instead of > this module. Here's a description of the method I am trying to implement. > > I want to map a machine (via hostname) to a machine owner. For example, the > following nodes would exist in the zookeeper with the following contents: > > - /authdb/owner_principal_machines/ops-full: > u23-r8.region1.localdomain > u24-r23.region1.localdomain > - /authdb/owner_principal_machines/ops-n00b: > u12-r7.region1.localdomain > u13-r8.region1.localdomain > > If the machine u23-r8.region1.localdomain (owned by dbmaster according to > the nodes above) connects to zookeeper, I would like it to be able to do > the CLI equivalent of "addauth authdb" to authenticate as the dbmaster > role. > > For flexibility, there are also hierarchical roles, which are also > represented with nodes. Those nodes would look like the following: > > - /authdb/principal_children/ops > ops-full > ops-limited > - /authdb/principal_children/ops-app1 > ops > - /authdb/principal_parents/ops-full > ops > ops-app1 > - /authdb/principal_parents/ops-limited > ops > ops-app1 > > Note that each of the nodes is a full expansion so that only one node needs > to be consulted when determining a match for an id to an ACL. > > These particular nodes would indicate that any machines owned by the > "ops-full" or "ops-limited" would also match the when the ACL was for the > "ops" id as well as their own names. > > Perhaps open a client connection from the auth provider itself? (i'm > > not sure if this would work, I don't think anyone ever tried it) > > > > Is there any way to get the configuration information so that I can get the > server names from there, or is there some other way to discover the server > names from within the server process so that I don't have to hard code it > in some other way? > > > > > Also, I've been unable to send message to this list from another email > > > address. I keep getting bounces claiming that the message is spammy. Is > > > anyone else getting rejected similarly? > > > > I haven't heard anything like that. You might check with the Apache > > infra team, they manage the mailing lists (outside regular > > moderation). > > > > Thanks for the info. I sent a message to the [email protected] alias. Will > that go anywhere useful? > > Thanks, > wt > -- > *Warren Turkal* > Site Reliability Engineer | > [email protected] | 650-961-3400 > www.ooyala.com | blog <http://www.ooyala.com/blog> | > @ooyala<http://www.twitter.com/ooyala> >
