azkaban-aplcache
Details
docs/index.rst 1(+1 -0)
diff --git a/docs/index.rst b/docs/index.rst
index 51d65e9..ffac5aa 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -33,6 +33,7 @@ Features
getStarted
configuration
+ userManager
useAzkaban
eventTrigger
ajaxApi
docs/userManager.rst 198(+198 -0)
diff --git a/docs/userManager.rst b/docs/userManager.rst
new file mode 100644
index 0000000..162d14a
--- /dev/null
+++ b/docs/userManager.rst
@@ -0,0 +1,198 @@
+.. _configs:
+
+
+UserManager
+==================================
+
+When you start Azkaban, you may notice the login page. Azkaban makes you authenticate before you can use it.
+This is prevent seeing or executing workflows you shoudn’t see or touch.
+
+We also used authenticated users for auditing purposes. Whenever project files change, is modified, scheduled, etc.
+we often want to know which user performed that action.
+
+
+**user login in page:**
+
+.. image:: figures/login.png
+
+*****
+XmlUserManager
+*****
+
+The XmlUserManager is the default UserManager that is built into
+Azkaban. To explicitly set the parameters that configure the
+XmlUserManager, the following parameters can be set in the
+``azkaban.properties`` file.
+
++-----------------------+-----------------------------+
+| Parameter | Default |
++=======================+=============================+
+| user.manager.class | azkaban.user.XmlUserManager |
++-----------------------+-----------------------------+
+| user.manager.xml.file | azkaban-users.xml |
++-----------------------+-----------------------------+
+
+The other file that needs to be modified is the ``azkaban-users.xml``
+file. The XmlUserManager will parse the user xml file once during
+startup to set up the users.
+
+Everything must be enclosed in a ``<azkaban-users>`` tag. ::
+
+ <azkaban-users>
+ ...
+ </azkaban-users>
+
+Users
+**********************
+
+To add users, add the ``<user>`` tag.::
+
+ <azkaban-users>
+ <user username="myusername" password="mypassword" roles="a" groups="mygroup" / >
+ <user username="myusername2" password="mypassword2" roles="a, b" groups="ga, gb" / >
+ ...
+ </azkaban-users>
+
++-----------------------+-----------------------+-----------------------+
+| Attributes | Values | Required? |
++=======================+=======================+=======================+
+| username | The login username. | yes |
++-----------------------+-----------------------+-----------------------+
+| password | The login password. | yes |
++-----------------------+-----------------------+-----------------------+
+| roles | Comma delimited list | no |
+| | of roles that this | |
+| | user has. | |
++-----------------------+-----------------------+-----------------------+
+| groups | Comma delimited list | no |
+| | of groups that the | |
+| | users belongs to. | |
++-----------------------+-----------------------+-----------------------+
+| proxy | Comma delimited list | no |
+| | of proxy users that | |
+| | this users can give | |
+| | to a project | |
++-----------------------+-----------------------+-----------------------+
+
+Groups
+**********************
+
+To add users, add the ``<group>`` tag.::
+
+ <azkaban-users>
+ <user username="a" ... groups="groupa" / >
+ ...
+ <group name="groupa" roles="myrole" / >
+ ...
+ </azkaban-users>
+
+In the previous example, user 'a' is in the group 'groupa'. User 'a'
+would also have the 'myrole' role. A regular user cannot add group
+permissions to a project unless they are members of that group.
+
+The following are some group attributes that you can assign.
+
++------------+---------------------------------------------------+-----------+
+| Attributes | Values | Required? |
++============+===================================================+===========+
+| name | The group name | yes |
++------------+---------------------------------------------------+-----------+
+| roles | Comma delimited list of roles that this user has. | no |
++------------+---------------------------------------------------+-----------+
+
+
+Roles
+**********************
+Roles are different in that it assigns global permissions to users in
+Azkaban. You can set up roles with the ``<roles>`` tag.::
+
+ <azkaban-users>
+ <user username="a" ... groups="groupa" roles="readall" / >
+ <user username="b" ... / >
+ ...
+ <group name="groupa" roles="admin" / >
+ ...
+ <role name="admin" permissions="ADMIN" / >
+ <role name="readall" permissions="READ" / >
+ </azkaban-users>
+
+In the above example, user 'a' has the role 'readall', which is defined
+as having the READ permission. This means that user 'a' has global READ
+access on all the projects and executions.
+
+User 'a' also is in 'groupa', which has the role ADMIN. It's certainly
+redundant, but user 'a' is also granted the ADMIN role on all projects.
+
+The following are some group attributes that you can assign.
+
++-------------+------------------------------------------------------+-----------+
+| Attributes | Values | Required? |
++=============+======================================================+===========+
+| name | The group name | yes |
++-------------+------------------------------------------------------+-----------+
+| permissions | Comma delimited list global permissions for the role | yes |
++-------------+------------------------------------------------------+-----------+
+
+The possible role permissions are the following:
+
++-----------------------------------+-----------------------------------+
+| Permissions | Values |
++===================================+===================================+
+| ADMIN | Grants all access to everything |
+| | in Azkaban. |
++-----------------------------------+-----------------------------------+
+| READ | Gives users read only access to |
+| | every project and their logs |
++-----------------------------------+-----------------------------------+
+| WRITE | Allows users to upload files, |
+| | change job properties or remove |
+| | any project |
++-----------------------------------+-----------------------------------+
+| EXECUTE | Allows users to trigger the |
+| | execution of any flow |
++-----------------------------------+-----------------------------------+
+| SCHEDULE | Users can add or remove schedules |
+| | for any flows |
++-----------------------------------+-----------------------------------+
+| CREATEPROJECTS | Allows users to create new |
+| | projects if project creation is |
+| | locked down |
++-----------------------------------+-----------------------------------+
+
+*****
+Custom User Manager
+*****
+
+Although the XmlUserManager is easy enough to get started with, you may
+want to integrate with an already established directory system, such as
+LDAP.
+
+It should be fairly straight forward to implement a custom UserManager.
+The UserManager is a java interface. There are only a few methods needed
+to implement.::
+
+ public interface UserManager {
+ public User getUser(String username, String password) throws UserManagerException;
+ public boolean validateUser(String username);
+ public boolean validateGroup(String group);
+ public Role getRole(String roleName);
+ public boolean validateProxyUser(String proxyUser, User realUser);
+ }
+
+The constructor should take an ``azkaban.utils.Props`` object. The
+contents of ``azkaban.properties`` will be available for the UserManager
+for configuration.
+
+Package your new custom UserManager into a jar and drop it into the
+``./extlib`` directory or alternatively into the plugins directory (i.e.
+``./plugins/ldap/linkedin-ldap.jar``).
+
+Change the ``azkaban.properties`` configuration to point to the custom
+UserManager. Add additional parameters into ``azkaban.properties`` if
+needed by your custom user manager.
+
++------------------------+------------------------------------+
+| Parameter | Default |
++========================+====================================+
+| ``user.manager.class`` | ``azkaban.user.CustomUserManager`` |
++------------------------+------------------------------------+