[
https://issues.apache.org/jira/browse/HADOOP-10868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14127812#comment-14127812
]
Alejandro Abdelnur commented on HADOOP-10868:
---------------------------------------------
*AuthenticationFilter.java*:
The following code seems it could be (most of it) push down to each provider
impl:
{code}
if (signerSecretProviderName.equals("string")) {
String signatureSecret =
config.getProperty(configPrefix + SIGNATURE_SECRET, null);
secretProvider = new StringSignerSecretProvider(signatureSecret);
} else if (signerSecretProviderName.equals("random")) {
secretProvider = new RandomSignerSecretProvider();
randomSecret = true;
} else if (signerSecretProviderName.equals("zookeeper")) {
Object curatorClientObj = filterConfig.getServletContext()
.getAttribute(
ZOOKEEPER_SIGNER_SECRET_PROVIDER_CURATOR_CLIENT_ATTRIBUTE);
if (curatorClientObj != null
&& curatorClientObj instanceof CuratorFramework) {
secretProvider =
new ZKSignerSecretProvider((CuratorFramework) curatorClientObj);
} else {
secretProvider = new ZKSignerSecretProvider();
}
{code}
I would have a a function that gives me the Class of the provider, i.e.:
{code}
private Class<? extends SignerSecretProvider> getProviderClass(String name) {
if ("random".equals(name)) {
name = RandomSignerSecretProvider.class.getName();
} else if ("string".equals(name)) {
name = StringSignerSecretProvider.class.getName();
} else if ("zookeeper".equals(name)) {
name = ZookeeperSignerSecretProvider.class.getName();
}
name = RandomSignerSecretProvider.class.getName();
}
try {
return (Class<SignerSecretProvider>) Thread.currentThread().
getContextClassLoader().loadClass(signerSecretProviderName);
} catch (Exception ex) {
throw new ServletException(ex);
}
}
{code}
Then I would use {{ReflectionUtils.newInstance(providerClass, conf)}} to
instantiate it.
I would add {{ServletContext}} as param to the {{init()}} method which in the
case of ZK impl would be used to retrieve the curator from the context or
create a new one (all within the ZK impl). For the string impl, the string
secret would obtained from the config properties of the {{init()}}.
*hadoop-auth/pom.xml*:
* curator-test should be with scope 'test'
*ZKSignerSecretProvider.java*:
* line 334, log message, type 'occured'
* the ser/deser of the data we store in zookeeper, please add a version number
at the beginning. This will allow us to change things in the future and support
rolling upgrades.
* once you have a curator client, it will handle reconnections correctly? else
the {{createCuratorClient}} should be you have to be redo after a failed
attempt.
* I don’t like that ZK uses system properties for the auth info, but I guess
that is has to be :(. I’ll dig into this a bit while you take care of the other
feedback.
> Create a ZooKeeper-backed secret provider
> -----------------------------------------
>
> Key: HADOOP-10868
> URL: https://issues.apache.org/jira/browse/HADOOP-10868
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Affects Versions: 2.4.1
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Attachments: HADOOP-10868.patch, HADOOP-10868.patch,
> HADOOP-10868.patch, HADOOP-10868_branch-2.patch, HADOOP-10868_branch-2.patch,
> HADOOP-10868_branch-2.patch
>
>
> Create a secret provider (see HADOOP-10791) that is backed by ZooKeeper and
> can synchronize amongst different servers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
