::Go back to Oozie Documentation Index::
Oozie is a workflow scheduling solution for pure Grid processing that needs to support the different job types existing in a Grid environment (M/R, PIG, Streaming, HDFS, etc.). This scheduling system is data aware, extensible, scalable and light-weight. As Oozie is envisioned as a geteway for the grid for all the batch processing needs, it has to be aware of all other data processing systems which are getting used or will be used in the future for these purposes.
As Secure Hadoop is being used for the data processing then all components which have been built on hadoop will be using the same/different model for security needs and have their own security model to authenticate users. Now all the jobs are going through Oozie for hadoop and then for these systems, Oozie should be having a singular interface and support for different implementations of these credentials modules. Using those Oozie will authenticate users with all those systems and run job seamlessly.
Lets take an Example, User has a system lets call it ABC, which he wants to use for running his job. Now it has same policy like hadoop for delegation token for running job or that system provides certificates for running that job. So user should have way to plugin their system's credentials policy in Oozie in order to run those jobs.
This module facilitates users to provide credentials for any other systems user may want to use for running their jobs through Oozie if they follow the same interface and provide the implementation for those systems.
We have couple of options for implementation that are as follows:
Following section will discuss about their pros and cons and why we chose the second option.
In this option Oozie would have introduced multiple authentication actions and User will be using those actions ahead of their workflows to first get all the necessary credentials and pass those credentials to all the underneath actions in the workflows. For Example if user wants to use M/R actions and Pig Actions using ABC system then they first need to add ABC Action ahead of MR and Pig Actions and then oozie server will run ABC action on the gateway(oozie server) and provide all the necessary credentials to following actions.
This is a nice approach however there are couple of shortcomings with this approach those are as follows.
The solution to above mentioned problem is to make each action responsible for its own needs, in this case credential token for different systems. Currently too it is implemented in such a way for name node and job tracker. Every actions gets the token for itself for hdfs.
In this approach user will provide configuration for each workflow for all the needed/available credentials modules as well as user will also provide for each action, what are the credentials needed. Every action before running will call the appropriate credential modules to get the tokens and pass them in job conf for the tasks.
Shortcoming to this approach is every action has to authenticate itself but as of now there is no other way we can avoid that because of Token expiration problem. Perhaps one workflow may now authenticate many times with the same service, and that puts load on the auth service. There could be a de-authentication step after the action finishes in the future, if this turns out to be a problem.
We have one assumption in this approach which is to pass the delegation tokens in the job conf. Without jobconf this approach will not work. However we use jobconf for passing the Namenode and Jobtracker token . So without jobconf we need to rearchitect that design as well. For now its safe to assume we will have job conf.
User has to add following configuration to their workflow.xml. Please find below workflow xml for reference.
<workflow-app xmlns='uri:oozie:workflow:0.1' name='pig-wf'>
...
<credentials>
<credential name='howlauth' type='hcat'>
<property>
<name>hcat.metastore.uri</name>
<value>HCAT_URI</value>
</property>
<property>
<name>hcat.metastore.principal</name>
<value>HCAT_PRINCIPAL</value>
</property>
</credential>
</credentials>
...
<action name='pig' cred='howlauth'>
<pig>
<job-tracker>JT</job-tracker>
<name-node>NN</name-node>
<configuration>
<property>
<name>TESTING</name>
<value>${start}</value>
</property>
</configuration>
</pig>
</action>
...
</workflow-app>
If User wants to plugin the new Authentication module for their needs, they have to specify that in oozie-default.xml under the following property oozie.credentials.credentialclasses ABC=oorg.apache.oozie.action.hadoop.InsertTestToken
This is the sample class how users can write their Token class
public class InsertTestToken extends Credentials{public InsertTestToken() {
}
/* (non-Javadoc)
* @see org.apache.oozie.action.hadoop.Credentials#addtoJobConf(org.apache.hadoop.mapred.JobConf,
org.apache.oozie.action.hadoop.CredentialsProperties, org.apache.oozie.action.ActionExecutor.Context)
*/
@Override
public void addtoJobConf(JobConf jobconf, CredentialsProperties props, Context context) throws Exception {
try {
Token<DelegationTokenIdentifier> abctoken = new Token<DelegationTokenIdentifier>();
jobconf.getCredentials().addToken(new Text("ABC Token"), abctoken);
XLog.getLog(getClass()).debug("Added the ABC token in job conf");
}
catch (Exception e) {
XLog.getLog(getClass()).warn("Exception in addtoJobConf", e);
throw e;
}
}
}