Oozie provides a simple authorization model.
Oozie does not provide authentication or authorization checks out of the box.
Oozie provides a plugglable mechanism to easily integrate existing authentication and authorization services.
If Oozie security is disabled, all users are admin users.
Oozie security is disabled by default, to enabled it the oozie.service.AuthorizationService.security.enabled property must be set to true .
All interaction with Oozie is via Web Services implemented as Java Servlets.
Authentication can be enforced via a Java Servlet Filter.
The filter should only allow requests that contain valid credentials (i.e. HTTP basic authorization, cookies).
If the request does not contain valid credentials the filter must return the HTTP UNAUTHORIZED (401) error code.
If the request does contain valid credetials, the filter must set the user name as the oozie.user.name attribute in the request before dispaching the request with the doChain() method.
Oozie provides an AuthorizationService that enforces Oozie authorization model for administration and jobs.
However it does not validate user-group information against any store.
The user-group information for the default AuthorizationService is:
The AuthorizationService should be subclassed and the following methods should be overriden:
The default AuthorizationService provides a basic mechanism to define admin users.
The list of admin users is configured by adding 1 user per line to a file adminusers.txt , and placing this file in the Oozie Configuration directory. Empty lines and lines starting with '#' are ignored.
The Oozie configuration directory is specified by setting the property 'oozie.config.dir'. Refer to Oozie Install for details.
Write requests are logged in an audit log (oozie-audit.log). This log is not rotated This log captures the following information.