Click here for Reference Manual which shows how the Command Line Interpreter drives the Fortress APIs from a command prompt.

## Instructions to start and use the Fortress CLI program

Note: Information to set up environment of Fortress runtime, check out file named README.txt found in root folder of Fortress SDK package.

1. Open shell prompt within FORTRESS_HOME folder and enter the following
2. export JAVA_HOME=/path to the root folder of your java SDK, version 7 and beyond required
3. export M2_HOME=/path to the root folder of your Apache Maven installation, version 3 and beyond required
4. $M2_HOME/bin/mvn -Pcli test
5. This will fire Fortress ant target which then starts the CLI. The CLI syntax will be described in detail below.

## Command Line Interpreter Reference Manual

Once started, the Fortress CLI runs in interactive mode which means it runs continuously waiting for user to enter a valid commands or terminate. Every CLI command is structured in the following format:

group function options

For example:

    admin auser -u hounddog42 -p myNewP@$$w0rd -o development

In this example the group is 'admin', the function is 'auser' or add user, and the options are -u for userid, -p for password and -o that points to a valid USERS OrgUnit node. Despite being called an 'option', so named parameters may or may not be required for a given function. Option names are always preceded by a dash ('-') when entered. Option values must be enclosed within single quotes '' or double quotes "" if value contains multiple Strings separated by whitespace. For example the user description value can be entered like this: -d "This description contains more than one word" or this: -d 'This description also contains more than one word'.
Below is reference manual for Fortress' CLI commands

## Groups

Currently the following groups of functions are supported:

- admin - used to setup RBAC policies
- review - used to interrogate RBAC policies
- system - used to test RBAC policies
- dadmin - used to setup ARBAC (administrative role based access control) policies
- group - used to setup LDAP Group policies

## Sample run to add new User to LDAP

            [echo] Run the Fortress Command Line Interpreter
            [java] 2011-12-03 21:10:02,431 (INFO ) CLI Options include admin, review, system, dadmin
            [java] 2011-12-03 21:10:02,431 (INFO ) Enter one from above or 'q' to quit
            admin auser -u hounddog42 -p myNewP@$$w0rd -o development
                 [java] 2011-12-03 21:41:37,614 (INFO ) arg:admin
                 [java] 2011-12-03 21:41:37,614 (INFO ) arg:auser
                 [java] 2011-12-03 21:41:37,615 (INFO ) arg:-u
                 [java] 2011-12-03 21:41:37,615 (INFO ) arg:hounddog42
                 [java] 2011-12-03 21:41:37,615 (INFO ) arg:-p
                 [java] 2011-12-03 21:41:37,616 (INFO ) arg:-o
                 [java] 2011-12-03 21:41:37,616 (INFO ) arg:development
                 [java] 2011-12-03 21:41:37,617 (INFO ) auser
                 [java] 2011-12-03 21:41:37,750 (INFO ) command:auser was successful
                 [java] 2011-12-03 21:41:37,750 (INFO ) CLI Options include admin, review, system, dadmin
                 [java] 2011-12-03 21:41:37,751 (INFO ) Enter one from above or 'q' to quit

This remainder of document is a command reference document to show how the Fortress CLI works.

1. ## Administrative Commands

   This section contains a guide for the functions and options that fall in the admin group.

   1. ### auser : function to add a new User

      This command creates a new RBAC user. The command is valid only if the new user is not already a member of the USERS data set. The USER data set is updated. The new user does not own any session at the time of its creation.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid
      - p : password - used to authenticate the User
      - o : orgUnit - contains the name of an already existing User OU node

      #### optional parameters

      - w : pwPolicy - contains the name of an already existing password policy node
      - c : cn - maps to INetOrgPerson common name attribute
      - s : sn - maps to INetOrgPerson surname attribute
      - d : description - maps to INetOrgPerson description attribute
      - 3 : title - maps to INetOrgPerson title attribute
      - 4 : employeeType - maps to INetOrgPerson employeeType attribute
      - y : phones * - multivalued attribute maps to organizationalPerson telephoneNumber attribute
      - Y : mobiles * - multivalued attribute maps to INetOrgPerson mobile attribute
      - & : emails * - multivalued attribute maps to INetOrgPerson mail attribute
      - > : address * - multivalued attribute maps to organizationalPerson postalAddress attribute
      - < : state - maps to organizationalPerson st attribute
      - 3 : city - maps to organizationalPerson l attribute
      - z : postalCode - maps to postalCode description attribute
      - 2 : postalOfficeBox - maps to organizationalPerson postOfficeBox attribute
      - b : beginTime - HHMM - determines begin hour user may activate session
      - e : endTime - HHMM - determines end hour user may activate session.
      - B : beginDate - YYYYMMDD - determines date when user may sign on
      - E : endDate - YYYYMMDD - indicates latest date user may sign on
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day of user may sign on
      - t : timeout - number (in minutes) of session inactivity time allowed
      - v : properties * - multivalued attribute contains property key and values are separated with a ':'. e.g. mykey1:myvalue1
      - r : roles * - multivalued attribute contains the name of already existing role to assign to user
      - a : adminRoles * - multivalued attribute contains the name of already existing adminRole to assign to user
      - X : protocol - alphanumeric string used for groups
      - M : member - contains userId of member to a group

      #### example

      - admin auser -u testuser1 -p mypasword123 -o dev1
      - admin auser -u testuser2 -p mypasword456 -o dev1 -r oamRole1 -d mydescription -b 0800 -e 1700 -B 20111203 -E 20111231 -l 20111215 -n 20111217 -m 17 -t 30 -v n1:v1 -v n2:v2
      - admin auser -u testuser3 -p mypasword789 -o dev1 -z 1111111 -2 123 -y 555-555-5555 -y 444-444-4444 -> "joshuatree1 one two three" -> "joshuatree2 four five six" -> CA -3 twentyninepalms -Y 333-333-3333

   2. ### uuser : function to update an existing user in LDAP

      This method performs an update on User entity in directory. Prior to making this call the entity must exist in directory.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid

      #### optional parameters

      - p : password - used to authenticate the User
      - o : orgUnit - contains the name of an already existing User OU node
      - w : pwPolicy - contains the name of an already existing password policy node
      - c : cn - maps to INetOrgPerson common name attribute
      - s : sn - maps to INetOrgPerson surname attribute
      - d : description - maps to INetOrgPerson description attribute
      - 3 : title - maps to INetOrgPerson title attribute
      - 4 : employeeType - maps to INetOrgPerson employeeType attribute
      - y : phones * - multivalued attribute maps to organizationalPerson telephoneNumber attribute
      - Y : mobiles * - multivalued attribute maps to INetOrgPerson mobile attribute
      - & : emails * - multivalued attribute maps to INetOrgPerson mail attribute
      - > : address * - multivalued attribute maps to organizationalPerson postalAddress attribute
      - < : state - maps to organizationalPerson st attribute
      - 3 : city - maps to organizationalPerson l attribute
      - z : postalCode - maps to postalCode description attribute
      - 2 : postalOfficeBox - maps to organizationalPerson postOfficeBox attribute
      - b : beginTime - HHMM - determines begin hour user may activate session
      - e : endTime - HHMM - determines end hour user may activate session.
      - B : beginDate - YYYYYYMMDD - determines date when user may sign on
      - E : endDate - YYYYMMDD - indicates latest date user may sign on
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day of user may sign on
      - t : timeout - number (in minutes) of session inactivity time allowed
      - v : properties * - multivalued attribute contains property key and values are separated with a ':'. e.g. mykey1:myvalue1
      - r : roles * - multivalued attribute contains the name of already existing role to assign to user
      - a : adminRoles * - multivalued attribute contains the name of already existing adminRole to assign to user

      #### example

      - admin uuser -u testuser1 -d mynewdescription
      - admin uuser -u testuser2 -p mynewpasword456 -r oamRole2 -b 0805 -e 1701 -B 20111203 -E 20111231 -l 20111215 -n 20111217 -m 17 -t 30 -v n1:v1 -v n2:v2
      - admin uuser -u testuser3 -p password123 -z 1111111 -2 123 -y 555-555-5555 -y 444-444-4444 -> "joshuatree1 one two three" -> "joshuatree2 four five six" -< CA -3 twentyninepalms -Y 333-333-3333

   3. ### duser : function to delete a user from LDAP

      This command deletes an existing user from the RBAC database. The command is valid if and only if the user to be deleted is a member of the USERS data set. The USERS and UA data sets and the assigned_users function are updated. This method performs a "hard" delete. It completely removes all data associated with this user from the directory. User entity must exist in directory prior to making this call else exception will be thrown.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid

      #### example

      - admin duser -u testuser1

   4. ### change : function to change a user's password

      Password policies will be enforced if in effect at the time of this function call.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid
      - p : password - contains the User's old password
      - V : newPassword - contains the User's new password

      #### example

      - admin change -u testuser1 -p mypasword123 -V mynewpassword456

   5. ### reset : function to perform an administrative reset on user password

      Used by administrator to change a user's password when they have forgotten old password or if the password is expired. When policies are in effect this will force User to change their password the next time authenticate.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid
      - V : newPassword - contains the User's new password

      #### example

      - admin reset -u testuser1 -V temp777

   6. ### lock : LOCK_USER_ACCOUNT

      Used to lock a user's account in LDAP

      #### required parameters

      - u : userId - maps to INetOrgPerson uid

      #### example

      - admin lock -u testuser1

   7. ### unlock : UNLOCK_USER_ACCOUNT

      Used to unlock a user's account in so they may sign on again to LDAP. Note this will not fix an expired password (which needs to be changed by user or reset by admin)

      #### required parameters

      - u : userId - maps to INetOrgPerson uid

      #### example

      - admin unlock -u testuser1

   8. ### arole : Add a new Role

      This command creates a new role. The command is valid if and only if the new role is not already a member of the ROLES data set. The ROLES data set is updated. Initially, no user or permission is assigned to the new role.

      #### required parameters

      - n : name - contains the name to use for the Role to be created.

      #### optional parameters

      - d : description - maps to description attribute on organizationalRole object class
      - b : beginTime - HHMM - determines begin hour role may be activated into user's RBAC session
      - e : endTime - HHMM - determines end hour role may be activated into user's RBAC session.
      - B : beginDate - YYYYMMDD - determines date when role may be activated into user's RBAC session
      - E : endDate - YYYYMMDD - indicates latest date role may be activated into user's RBAC session
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's RBAC session

      #### example

      - admin arole -n trole1
      - admin arole -n trole2 -d roledescription -b 0900 -e 1800 -B 20120101 -E 20990101 -m 1234567

   9. ### urole : Update an existing Role

      Method will update a Role entity in the directory. The role must exist in role container prior to this call.

      #### required parameters

      - n : name - contains the name for already existing Role to be updated

      #### optional parameters

      - d : description - maps to description attribute on organizationalRole object class
      - b : beginTime - HHMM - determines begin hour role may be activated into user's RBAC session
      - e : endTime - HHMM - determines end hour role may be activated into user's RBAC session.
      - B : beginDate - YYYYMMDD - determines date when role may be activated into user's RBAC session
      - E : endDate - YYYYMMDD - indicates latest date role may be activated into user's RBAC session
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's RBAC session

      #### example

      - admin urole -n trole1 -d newdesc
      - admin urole -n trole2 -b 0800 -B 20111231 -m 23456

   10. ### drole : Delete a Role

       This command deletes an existing role from the RBAC database. The command is valid if and only if the role to be deleted is a member of the ROLES data set. If role assignments to USERS or PERMISSIONS exist this command will delete those as well.

       #### required parameters

       - n : name - contains the name for already existing Role to be deleted

       #### example

       - admin drole -n trole1

   11. ### asgnrole : Assign a Role to a User

       This command assigns a user to a role.

       - The command is valid if and only if:
       - The user is a member of the USERS data set
       - The role is a member of the ROLES data set
       - The user is not already assigned to the role
       - The SSD constraints are satisfied after assignment.

       Successful completion of this op, the following occurs:

       - User entity (resides in people container) has role assignment added to aux object class attached to actual user record.
       - Role entity (resides in role container) has userId added as role occupant.
       - (optional) Temporal constraints may be associated with `ftUserAttrs` aux object class based on:
         - b : beginTime - HHMM - determines begin hour role may be activated into user's RBAC session
         - e : endTime - HHMM - determines end hour role may be activated into user's RBAC session.
         - B : beginDate - YYYYMMDD - determines date when role may be activated into user's RBAC session
         - E : endDate - YYYYMMDD - indicates latest date role may be activated into user's RBAC session
         - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
         - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
         - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's RBAC session

       #### required parameters

       - n : name - contains the name for already existing Role to be assigned
       - u : userId - contains the userId for existing User

       #### optional parameters

       - b : beginTime - HHMM - determines begin hour role may be activated into user's RBAC session
       - e : endTime - HHMM - determines end hour role may be activated into user's RBAC session.
       - B : beginDate - YYYYMMDD - determines date when role may be activated into user's RBAC session
       - E : endDate - YYYYMMDD - indicates latest date role may be activated into user's RBAC session
       - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
       - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
       - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's RBAC session

       #### example

       - admin asgnrole -u testuser2 -n trole2
       - admin asgnrole -u testuser2 -n trole2 -b 1200 -e 2359 -B 20120101 -E 20120131 -m 1234567

   12. ### dsgnrole : Deassign a Role from a User

       This command deletes the assignment of the User from the Role entities. The command is valid if and only if the user is a member of the USERS data set, the role is a member of the ROLES data set, and the user is assigned to the role. Any sessions that currently have this role activated will not be effected.

       Successful completion includes:
       - User entity in USER data set has role assignment removed.
       - Role entity in ROLE data set has userId removed as role occupant.
       - (optional) Temporal constraints will be removed from user aux object if set prior to call.

       #### required parameters

       - n : name - contains the name for already existing Role to be deassigned
       - u : userId - contains the userId for existing User

       #### example

       - admin dsgnrole -u testuser2 -n trole2

   13. ### arel : ADD_ROLE_INHERITANCE

       This commands establishes a new immediate inheritance relationship parentRole <<-- childRole between existing roles parentRole, childRole.

       The command is valid if and only if:

       - The parentRole and childRole are members of the ROLES data set.
       - The parentRole is not an immediate ascendant of childRole.
       - The childRole does not properly inherit parentRole (in order to avoid cycle creation).

       #### required parameters

       - A : ascendant - contains the name of existing Role to be parent
       - D : descendant - contains the name of existing Role to be child

       #### example

       - admin arel -A trole1 -D trole2

   14. ### drel : DELETE_ROLE_INHERITANCE

       This command deletes an existing immediate inheritance relationship parentRole <<-- childRole.

       command is valid if and only if:

       - The roles parentRole and childRole are members of the ROLES data set.
       - The parentRole is an immediate ascendant of childRole.
       - The new inheritance relation is computed as the reflexive-transitive closure of the immediate inheritance relation resulted after deleting the relationship parentRole <<-- childRole.

       #### required parameters

       - A : ascendant - contains the name of parent Role to be removed as parent
       - D : descendant - contains the name of child Role to be removed as child

       #### example

       - admin drel -A trole1 -D trole2

   15. ### asset : CREATE_SSD_SET

       This command creates a named SSD set of roles and sets the cardinality n of its subsets that cannot have common users.

       The command is valid if and only if:

       - The name of the SSD set is not already in use.
       - All the roles in the SSD set are members of the ROLES data set.
       - n is a natural number greater than or equal to 2 and less than or equal to the cardinality of the SSD role set.
       - The SSD constraint for the new role set is satisfied.

       #### required parameters

       - n : name - contains the name of new SSD role set to be added

       #### optional parameters

       - r : roles * - multivalued attribute contains the RBAC Role names to be added to this set
       - C : cardinality - default is 2 which is one more than maximum number of Roles that may be assigned to User from a particular set
       - d : description - contains any safe text

       #### example

       - admin asset -n mytestssd -r trole1 -r trole3 -r trole5 -r trole6 -c 2 -d only1of4canAssign
       - admin asset -n mytestssd -r trole1 -r trole3 -r trole5 -r trole6 -c 3 -d only2of4canAssign

   16. ### dsset : DELETE_SSD_SET

       This command deletes a SSD role set completely. The command is valid if and only if the SSD role set exists.

       #### required parameters

       - n : name - contains the name of existing SSD role set to be removed

       #### example

       - admin dsset -n mytestssd

   17. ### adset : CREATE_DSD_SET

       This command creates a named DSD set of roles and sets an associated cardinality n. The DSD constraint stipulates that the DSD role set cannot contain n or more roles simultaneously active in the same session.

       The command is valid if and only if:

       - The name of the DSD set is not already in use.
       - All the roles in the DSD set are members of the ROLES data set.
       - n is a natural number greater than or equal to 2 and less than or equal to the cardinality of the DSD role set.
       - The DSD constraint for the new role set is satisfied.

       #### required parameters

       - n : name - contains the name of new DSD role set to be added

       #### optional parameters

       - r : roles * - multivalued attribute contains the RBAC Role names to be added to this set
       - C : cardinality - default is 2 which is one more than maximum number of Roles that may be activated into RBAC Session from a particular set
       - d : description - contains any safe text

       #### example

       - admin adset -n mytestdsd -r trole1 -r trole3 -r trole5 -r trole6 -c 2 -d only1of4canActivate
       - admin adset -n mytestdsd -r trole1 -r trole3 -r trole5 -r trole6 -c 3 -d only2of4canActivate

   18. ### ddset : DELETE_DSD_SET

       This command deletes a DSD role set completely. The command is valid if and only if the DSD role set exists.

       #### required parameters

       - n : name - contains the name of existing DSD role set to be removed

       #### example

       - admin ddset -n mytestdsd

   19. ### aobj : ADD_POBJ

       This method will add permission object to perms container in directory. The perm object must not exist before making this call. A PermObj instance exists in a hierarchical, one-many relationship between itself and children as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of new object being added
       - o : orgUnit - contains the name of an existing PERMS OrgUnit this object is associated with

       #### optional parameters

       - d : description - any safe text
       - T : type - contains any safe text
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1

       #### example

       - admin aobj -n mytestobject -o app1
       - admin aobj -n myobject2 -o app1 -d TestObject -t anything -v key1:val1 -v key2:val2

   20. ### uobj : UPDATE_POBJ

       This method will update permission object in perms container in directory. The perm object must exist before making this call. A PermObj instance exists in a hierarchical, one-many relationship between itself and children as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of exising object being updated

       #### optional parameters

       - o : orgUnit - contains the name of an existing PERMS OrgUnit this object is associated with
       - d : description - any safe text
       - T : type - contains any safe text
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1

       #### example

       - admin uobj -n mytestobject -o app2 -d ChangedOrgUnit
       - admin uobj -n myobject2 -o app1 -d ChangeDescription

   21. ### dobj : DELETE_POBJ

       This method will remove permission object to perms container in directory. This method will also remove in associated permission objects that are attached to this object.

       #### required parameters

       - n : name - contains the name of exising object being targeted for removal

       #### example

       - admin dobj -n mytestobject -o app1

   22. ### aperm : ADD_PERM

       This method will add permission operation to an existing permission object which resides under ou=Permissions,ou=RBAC,dc=yourHostName,dc=com container in directory information tree. The perm operation entity may have Role or User associations. The target Permission must not exist prior to calling. A Fortress Permission instance exists in a hierarchical, one-many relationship between its parent and itself as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of existing object being targeted for the permission add
       - O : opName - contains the name of new permission operation being added

       #### optional parameters

       - r : roles * - multi occurring attribute contains RBAC Roles that permission operation is being granted to
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1
       - T : type - any safe text

       #### example

       - admin aperm -n mytestobject -O myoperation -d CreateNewPermission
       - admin aperm -n myobject2 -O myoperation2 -r trole1 -r trole5

   23. ### uperm : UPDATE_PERM

       This method will update permission operation pre-existing in target directory under ou=Permissions,ou=RBAC,dc=yourHostName,dc=com container in directory information tree. The perm operation entity may also contain Role or User associations to add or remove using this function. The perm operation must exist before making this call. Only non-null attributes will be updated.

       #### required parameters

       - n : name - contains the name of existing object being targeted for the permission update
       - O : opName - contains the name of existing permission operation being updated

       #### optional parameters

       - r : roles * - multivalued attribute contains RBAC Roles that permission operation is being granted to
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1
       - T : type - any safe text

       #### example

       - admin uperm -n myobject2 -O myoperation2 -r trole6 -D ReplaceExistingGrantsWithThisRole

   24. ### dperm : DELETE_PERM

       This method will remove permission operation entity from permission object. A Fortress permission is PermObj*->Permission. The perm operation must exist before making this call.

       #### required parameters

       - n : name - contains the name of existing object being targeted for the permission delete
       - O : opName - contains the name of existing permission operation that will be deleted

       #### example

       - admin dperm -n mytestobject -O myoperation -d CreateNewPermission

   25. ### grant : GRANT

       This command grants a role the permission to perform an operation on an object to a role. The command is implemented by granting permission by setting the access control list of the object involved. The command is valid if and only if the pair (operation, object) represents a permission, and the role is a member of the ROLES data set.

       #### required parameters

       - n : name - contains the object name
       - O : opName - contains the operation name
       - R : roleName - contains the role name

       #### example

       - admin grant -n mytestobject -O myoperation -R trole1

   26. ### revoke : REVOKE

       This command revokes the permission to perform an operation on an object from the set of permissions assigned to a role. The command is implemented by setting the access control list of the object involved. The command is valid if and only if the pair (operation, object) represents a permission, the role is a member of the ROLES data set, and the permission is assigned to that role.

       #### required parameters

       - n : name - contains the object name
       - O : opName - contains the operation name
       - R : roleName - contains the role name

       #### example

       - admin revoke -n mytestobject -O myoperation -R trole1

2. ### Delegated Admin Commands

   1. ### arole : Add a new ADMIN_Role

      This command creates a new admin role. The command is valid if and only if the new admin role is not already a member of the ADMIN ROLES data set. The ADMIN ROLES data set is updated. Initially, no user or permission is assigned to the new role.

      #### required parameters

      - n : name - contains the name of the new AdminRole being targeted for addition to LDAP

      #### optional parameters

      - d : description - contains any safe text
      - P : osPs * - multivalued attribute used to set associations to existing PERMS OrgUnits
      - U : osUs * - multivalued attribute used to set associations to existing USERS OrgUnits
      - x : beginRange - contains the name of an existing RBAC Role that represents the lowest role in hierarchy that administrator (whoever has this AdminRole activated) controls
      - w : endRange - contains the name of an existing RBAC Role that represents that highest role in hierarchy that administrator may control
      - y : beginInclusive - if 'true' the RBAC Role specified in beginRange is also controlled by the posessor of this AdminRole
      - z : endInclusive - if 'true' the RBAC Role specified in endRange is also controlled by the administratrator
      - b : beginTime - HHMM - determines begin hour adminRole may be activated into user's ARBAC session
      - e : endTime - HHMM - determines end hour adminRole may be activated into user's ARBAC session.
      - B : beginDate - YYYYMMDD - determines date when adminRole may be activated into user's ARBAC session
      - E : endDate - YYYYMMDD - indicates latest date adminRole may be activated into user's ARBAC session
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's ARBAC session

      #### example

      - dadmin arole -n arole1
      - dadmin arole -n arole2 -P app1 -P app2 -U dev1 -U dev2 -x role3 -w role1 -y true -z true -d adminroledescription -b 0900 -e 1800 -B 20120101 -E 20990101 -m 1234567

   2. ### urole : Update an existing ADMIN_Role

      Method will update a admin Role entity in the directory. The role must exist in admin role container prior to this call.

      #### required parameters

      - n : name - contains the name of existing AdminRole being targeted for update

      #### optional parameters

      - d : description - contains any safe text
      - P : osPs * - multivalued attribute used to set associations to existing PERMS OrgUnits
      - U : osUs * - multivalued attribute used to set associations to existing USERS OrgUnits
      - x : beginRange - contains the name of an existing RBAC Role that represents the lowest role in hierarchy that administrator (whoever has this AdminRole activated) controls
      - w : endRange - contains the name of an existing RBAC Role that represents that highest role in hierarchy that administrator may control
      - y : beginInclusive - if 'true' the RBAC Role specified in beginRange is also controlled by the posessor of this AdminRole
      - z : endInclusive - if 'true' the RBAC Role specified in endRange is also controlled by the administratrator
      - b : beginTime - HHMM - determines begin hour adminRole may be activated into user's ARBAC session
      - e : endTime - HHMM - determines end hour adminRole may be activated into user's ARBAC session.
      - B : beginDate - YYYYMMDD - determines date when adminRole may be activated into user's ARBAC session
      - E : endDate - YYYYMMDD - indicates latest date adminRole may be activated into user's ARBAC session
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's ARBAC session

      #### example

      - dadmin urole -n arole1 -d updatedescription
      - dadmin urole -n arole2 -x role4 -w role1 -y true -z false

   3. ### drole : Delete an ADMIN_Role

      This command deletes an existing admin role from the ARBAC database. The command is valid if and only if the admin role to be deleted is a member of the ADMIN ROLES data set and has been deassigned from all users.

      #### required parameters

      - n : name - contains the name of existing AdminRole being targeted for deletion.

      #### example

      - dadmin drole -n arole1

   4. ### asgnrole : Assign an ADMIN_Role to a User

      This command assigns a user to an admin role. Successful completion of this op, the following occurs:

      - User entity (resides in people container) has role assignment added to aux object class attached to actual user record.
      - AdminRole entity (resides in admin role container) has userId added as role occupant.
      - (optional) Temporal constraints may be associated with `ftUserAttrs` aux object class based on:
      - timeout - number (in minutes) of session inactivity time allowed.
      - beginDate - YYYYMMDD - determines date when role may be activated.
      - endDate - YYYYMMDD - indicates latest date role may be activated.
      - beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - endLockDate - YYYYMMDD - determines end of enforced inactive status.
      - beginTime - HHMM - determines begin hour role may be activated in user's session.
      - endTime - HHMM - determines end hour role may be activated in user's session.*
      - dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day of week role may be activated.

      #### required parameters

      - n : name - contains the name for already existing AdminRole to be assigned
      - u : userId - contains the userId for existing User

      #### optional parameters

      - b : beginTime - HHMM - determines begin hour AdminRole may be activated into user's RBAC session
      - e : endTime - HHMM - determines end hour AdminRole may be activated into user's RBAC session.
      - B : beginDate - YYYYMMDD - determines date when AdminRole may be activated into user's RBAC session
      - E : endDate - YYYYMMDD - indicates latest date AdminRole may be activated into user's RBAC session
      - l : beginLockDate - YYYYMMDD - determines beginning of enforced inactive status
      - N : endLockDate - YYYYMMDD - determines end of enforced inactive status
      - m : dayMask - 1234567, 1 = Sunday, 2 = Monday, etc - specifies which day role may be activated into user's ARBAC session

      #### example

      - dadmin asgnrole -u testuser2 -n arole1
      - dadmin asgnrole -u testuser2 -n arole2 -b 1200 -e 2359 -B 20120101 -E 20120131 -m 1234567
   \

   5. ### dsgnrole : Deassign a ADMIN_Role from a User

      This method removes assigned admin role from user entity. Both user and admin role entities must exist and have role relationship before calling this method. Successful completion: del Role to User assignment in User data set AND User to Role assignment in Admin Role data set.

      #### required parameters

      - n : name - contains the name for already existing AdminRole to be deassigned
      - u : userId - contains the userId for existing User

      #### example

      - dadmin dsgnrole -u testuser2 -n arole1

   6. ### arel : ADD_ADMIN_ROLE_INHERITANCE

      This commands establishes a new immediate inheritance relationship with parent orgunit <<-- child orgunit

      The command is valid if and only if:

      - The parent and child are members of the ORGUNITS data set.
      - The parent is not an immediate ascendant of child.
      - The child does not properly inherit parent (in order to avoid cycle creation).

      #### required parameters

      - A : ascendant - contains the name of parent AdminRole to be added as parent
      - D : descendant - contains the name of child AdminRole to be added as child

      #### example

      - dadmin arel -A arole1 -D arole2

   7. ### drel : DELETE_ADMIN_ROLE_INHERITANCE

      This command deletes an existing immediate inheritance relationship parent <<-- child.

      The command is valid if and only if:

      - The orgunits parent and child are members of the ORGUNITS data set.
      - The parent is an immediate ascendant of child.
      - The new inheritance relation is computed as the reflexive-transitive closure of the immediate inheritance relation resulted after deleting the relationship parent <<-- child.

      #### required parameters

      - A : ascendant - contains the name of parent AdminRole to be removed as parent
      - D : descendant - contains the name of child AdminRole to be removed as child

      #### example

      - dadmin drel -A arole1 -D arole2

   8. ### auou : ADD_USERORG

      Command adds a new USERS OrgUnit entity to OrgUnit dataset.

      #### required parameters

      - n : name - contains the name of new USERS OrgUnit to be added
      - d : description - contains any safe text

      #### example

      - dadmin auou -n UserOrg1
      - dadmin auou -n UserOrg2 -d description-contains-any-safe-text

   9. ### uuou : UPDATE_USERORG

      Command updates a USERS OrgUnit entity to OrgUnit dataset.

      #### required parameters

      - n : name - contains the name of existing USERS OrgUnit to be updated

      #### optional parameters

      - d : description - contains any safe text

      #### example

      - dadmin uuou -n UserOrg2 -d updated-description-contains-any-safe-text

   10. ### duou : DELETE_USERORG

       Command removes an existing USERS OrgUnit entity from the OrgUnit dataset.

       #### required parameters

       - n : name - contains the name of existing USERS OrgUnit to be deleted

       #### example

       - dadmin duou -n UserOrg1

   11. ### aurel : ADD_USERORG_INHERITANCE

       This commands establishes a new immediate inheritance relationship with parent USERS orgunit <<-- child orgunit

       The command is valid if and only if:

       - The parent and child are members of the USERS ORGUNITS data set.
       - The parent is not an immediate ascendant of child.
       - The child does not properly inherit parent (in order to avoid cycle creation).

       #### required parameters

       - A : ascendant - contains the name of existing USERS OrgUnit to be new parent
       - D : descendant - contains the name of existing USERS OrgUnit to be new child

       #### example

       - dadmin aurel -A UserOrg1 -D UserOrg2

   12. ### durel : DELETE_USERORG_INHERITANCE

       This command deletes an existing immediate inheritance relationship parent <<-- child.

       The command is valid if and only if:

       - The orgunits parent and child are members of the USERS ORGUNITS data set.
       - The parent is an immediate ascendant of child.
       - The new inheritance relation is computed as the reflexive-transitive closure of the immediate inheritance relation resulted after deleting the relationship parent <<-- child.

       #### required parameters

       - A : ascendant - contains the name of existing USERS OrgUnit to be removed as parent
       - D : descendant - contains the name of existing USERS OrgUnit to be removed as child

       #### example

       - dadmin durel -A UserOrg1 -D UserOrg2

   13. ### apou : ADD_PERMORG

       Command adds a new PERMS OrgUnit entity to OrgUnit dataset.

       #### required parameters

       - n : name - contains the name of new existing PERMS OrgUnit to be added
       - d : description - contains any safe text

       #### example

       - dadmin apou -n PermOrg1
       - dadmin apou -n PermOrg2 -d description-contains-any-safe-text

   14. ### upou : UPDATE_PERMORG

       Command updates a PERMS OrgUnit entity to OrgUnit dataset.

       #### required parameters

       - n : name - contains the name of existing PERMS OrgUnit to be updated

       #### optional parameters

       - d : description - contains any safe text

       #### example

       - dadmin upou -n PermOrg1 -d description-contains-any-safe-text

   15. ### dpou : DELETE_PERMORG

       Command removes an existing PERMS OrgUnit entity from the OrgUnit dataset.

       #### required parameters

       - n : name - contains the name of existing PERMS OrgUnit to be deleted

       #### example

       - dadmin dpou -n PermOrg2

   16. ### aprel : ADD_PERMORG_INHERITANCE

       This commands establishes a new immediate inheritance relationship with parent PERMS orgunit <<-- child orgunit

       The command is valid if and only if:

       - The parent and child are members of the USERS ORGUNITS data set.
       - The parent is not an immediate ascendant of child.
       - The child does not properly inherit parent (in order to avoid cycle creation).

       #### required parameters

       - A : ascendant - contains the name of existing PERMS OrgUnit to be new parent
       - D : descendant - contains the name of existing PERMS OrgUnit to be new child

       #### example

       - dadmin aprel -A PermOrg1 -D PermOrg2

   17. ### dprel : DELETE_PERMORG_INHERITANCE

       This command deletes an existing immediate inheritance relationship parent <<-- child.

       The command is valid if and only if:

       - The orgunits parent and child are members of the PERMS ORGUNITS data set.
       - The parent is an immediate ascendant of child.
       - The new inheritance relation is computed as the reflexive-transitive closure of the immediate inheritance relation resulted after deleting the relationship parent <<-- child.

       #### required parameters

       - A : ascendant - contains the name of existing PERMS OrgUnit to be removed as parent
       - D : descendant - contains the name of existing PERMS OrgUnit to be removed as child

       #### example

       - dadmin dprel -A PermOrg1 -D PermOrg2

   18. ### aobj : ADD_ADMIN_POBJ

       This method will add administrative permission object to perms container in directory. The perm object must not exist before making this call. A PermObj instance exists in a hierarchical, one-many relationship between itself and children as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of new administrative object being added
       - o : orgUnit - contains the name of an existing PERMS OrgUnit this administrative object is associated with

       #### optional parameters

       - d : description - contains safe text
       - T : type - any safe text
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1

       #### example

       - dadmin aobj -n mytestobject -o app1
       - dadmin aobj -n myobject2 -o app1 -d TestObject -t anything -v key1:val1 -v key2:val2

   19. ### uobj : UPDATE_ADMIN_POBJ

       This method will update an administrative permission object in perms container in directory. The perm object must exist before making this call. A PermObj instance exists in a hierarchical, one-many relationship between itself and children as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of existing administrative object being targeted for update

       #### optional parameters

       - o : orgUnit - contains the name of existing PERMS OrgUnit to associate administrative object with
       - d : description - contains any safe text
       - T : type - any safe text
       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1

       #### example

       - dadmin uobj -n mytestobject -o app2 -d ChangedOrgUnit
       - dadmin uobj -n myobject2 -o app1 -d ChangeDescription

   20. ### dobj : DELETE_POBJ

       This method will remove an administrative permission object to perms container in directory. This method will also remove in associated permission objects that are attached to this object.

       #### required parameters

       - n : name - contains the name of existing administrative object being targeted for delete

       #### example

       - dadmin dobj -n mytestobject -o app1

   21. ### aperm : ADD_ADMIN_PERM

       This method will add an administrative permission operation to an existing permission object which resides under ou=AdminPermis,ou=ARBAC,dc=yourHostName,dc=com container in directory information tree. The perm operation entity may have AdminRole or User associations. The target Permission must not exist prior to calling. A Fortress Administrative Permission instance exists in a hierarchical, one-many relationship between its parent and itself as stored in ldap tree: PermObj*->Permission.

       #### required parameters

       - n : name - contains the name of existing administrative object being targeted for the permission add
       - O : opName - contains the name of new administrative permission operation being added

       #### optional parameters

       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1
       - T : type - any safe text

       #### example

       - dadmin aperm -n mytestobject -O myoperation -d CreateNewAdminPermission

   22. ### uperm : UPDATE_ADMIN_PERM

       This method will update an administrative permission operation pre-existing in target directory under ou=AdminPermis,ou=ARBAC,dc=yourHostName,dc=com container in directory information tree. The perm operation entity may also contain AdminRole or User associations to add or remove using this function. The perm operation must exist before making this call. Only non-null attributes will be updated.

       #### required parameters

       - n : name - contains the name of existing administrative object being targeted for the permission update
       - O : opName - contains the name of existing administrative permission operation being updated

       #### optional parameters

       - v : properties * - multi-occurring property key and values are separated with a ':'. e.g. mykey1:myvalue1
       - T : type - any safe text

       #### example

       - dadmin uperm -n mytestobject -O myoperation -d new-description

   23. ### dperm : DELETE_ADMIN_PERM

       This method will remove an administrative permission operation entity from permission object. A Fortress administrative permission is PermObj*->Permission. The perm operation must exist before making this call.

       #### required parameters

       - n : name - contains the name of existing administrative object being targeted for the permission delete
       - O : opName - contains the name of existing administrative permission operation that will be deleted

       #### example

       - dadmin dperm -n mytestobject -O myoperation -d CreateNewAdminPermission

   24. ### grant : GRANT ADMIN

       This command grants an adminRole the administrative permission to perform an operation on an object to a role. The command is implemented by granting permission by setting the access control list of the object involved. The command is valid if and only if the pair (operation, object) represents a permission, and the role is a member of the ADMIN_ROLES data set.

       #### required parameters

       - n : name - contains the administrative object name
       - O : opName - contains the administrative operation name
       - R : roleName - contains the adminRole name

       #### example

       - dadmin grant -n mytestobject -O myoperation -R arole1

   25. ### revoke : REVOKE ADMIN

       This command revokes the permission to perform an operation on an object from the set of permissions assigned to an adminRole. The command is implemented by setting the access control list of the object involved. The command is valid if and only if the pair (operation, object) represents a permission, the role is a member of the ADMIN_ROLES data set, and the permission is assigned to that role.

       #### required parameters

       - n : name - contains the administrative object name
       - O : opName - contains the administrative operation name
       - R : roleName - contains the adminRole name

       #### example

       - dadmin revoke -n mytestobject -O myoperation -R arole1

3. ### Review Commands

   1. ### ruser : READ_USER

      This function reads a User object from the directory. The userId is not case sensitive.

      #### required parameters

      - u : userId - maps to INetOrgPerson uid

      #### example

      - review ruser -u testuser1

   2. ### fuser : FIND_USERS

      This function searches for matching users on the userId field. It uses a search filter of:

           String filter = "(&(objectclass=" + objectClassImpl + ")(" + GlobalIds.UID + "=" + searchVal + "*))";

      which will return all Users that match the leading characters of the search field which is case insensitive. This logs the results using log4j to allow output to be logged to console or file.

      #### required parameters

      - u : userId - contains the leading characters that map to INetOrgPerson uid field in LDAP

      #### example

      - review fuser -u test

   3. ### asgnuser : ASSIGNED_USERS

      This function returns all Users who are assigned a particular Role.

      #### required parameters

      - n : name - contains the name for already existing RBAC Role

      #### example

      Return all Users who are assigned an RBAC role named 'role1'.
      - review asgnuser -n -role1

   4. ### rrole : READ_ROLE

      This function reads a Role object from the directory. The Role name is not case sensitive.

      #### required parameters

      - n : name - contains the name for already existing RBAC Role

      #### example

      - review rrole -n role1

   5. ### frole : FIND_ROLES

      This function searches for matching Roles on the name field. It will return all Roles that match the leading characters of the search field which is case insensitive. This logs the results using log4j to allow output to be logged to console or file.

      #### required parameters

      - n : name - contains all or some of the leading characters to a matching set of Roles in the directory

      #### example

      Return all Roles where the name begins with the characters 'role':
      - review frole -n role

   6. ### robj : READ_POBJ

      This function reads a Permission Object from the directory. The object name is not case sensitive.

      #### required parameters

      - n : name - contains the name for already existing RBAC PermObj

      #### example

      - review robj -n mytestobject

   7. ### fobj : FIND_POBJS

      This function searches for matching Permission Objects on the name field. It will return all PermObjs that match the leading characters of the search field which is case insensitive. This logs the results using log4j to allow output to be logged to console or file.

      #### required parameters

      - n : name - contains all or some of the leading characters to a matching set of Permission Objects in the directory

      #### example

      Return all PermObjs where the name begins with the characters 'my':
      - review robj -n my

   8. ### rperm : READ_PERM

      This function reads a Permission Operation from the directory. The permission object and operation names are not case sensitive.

      #### required parameters

      - n : name - contains the name of existing object being targeted for the query
      - O : opName - contains the name of permission operation being targeted for the query

      #### example

      - review rperm -n mytestobject -O myoperation

   9. ### fperm : FIND_PERMS

      This function searches for matching Permission Operations on the name fields of the Permission Object and Operation attributes. It will return all Permissions that match the leading characters of the search fields which are not case insensitive. This logs the results using log4j to allow output to be logged to console or file.

      #### required parameters

      - n : name - contains all or some of the leading characters of the set of existing objects being targeted for the query
      - O : opName - contains all or some of the leading characters of the set of permission operations (that correpond with the result set of PermObjs) being targeted for the query

      #### example

      Return all Permissions where the Object name begins with name field 'mytest' and Operation name begins with the characters 'my':
      - review fperm -n mytest -O my

4. ### Group Commands

   1. ### agroup : ADD_GROUP

      This function adds a new LDAP group to the directory.

      #### required parameters

      - n : name - contains the name to use for new LDAP group. It must be unique.
      - M : members * - multivalued attribute (must include at least one) - maps to userId in LDAP directory"

      #### optional parameters

      - d : description - maps to description attribute on object class
      - X : protocol - used to specify protocol
      - v : properties * - multivalued attribute contains property key and values are separated with a '='. e.g.: key1=val1

      #### example

      - group agroup -n footest1 -d "Test LDAP Groups 001" -M demouser4 -v key1=val1 -v key2=val2 -X ssh
      - group agroup -n footest2 -d "Test LDAP Groups 001" -M demouser5 -M demouser6 -v key3=val3 -v key4=val4 -X rdp

   2. ### ugroup : UPDATE_GROUP

      Modify existing group node. The name is required. Does not update members or properties. Use ASSIGN_GROUP, DEASSIGN_GROUP, ADD_GROUP_PROP or DEL_GROUP_PROP for multivalued attributes.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.

      #### optional parameters

      - M : members * - multivalued attribute maps to a userId in the LDAP directory"
      - d : description - maps to description attribute on object class

      #### example

      - group ugroup -n footest1 -d "Update Test LDAP Groups 001" -X ssh2

   3. ### dgroup : DELETE_GROUP

      This function removes an LDAP group from the directory.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.

      #### example

      - group dgroup -n footest1

   4. ### asgngroup : ASSIGN_GROUP

      This function adds a user as a member to an existing LDAP group in the directory.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.
      - M : members * - multivalued attribute (must include at least one) - maps to userId in LDAP directory"

      #### example

      - group asgngroup -n footest1 -M demouser5

   5. ### dsgngroup : DEASSIGN_GROUP

      This function removes a user as a member from an existing LDAP group in the directory.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.
      - M : members * - multivalued attribute (must include at least one) - maps to userId in LDAP directory"

      #### example

      - group dsgngroup -n footest1 -M demouser5

   6. ### agprop : ADD_GROUP_PROP

      This function adds one or more properties to an existing LDAP group.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.
      - v : properties * - multi-occurring property key and values are separated with a '='. e.g. mykey1=myvalue1

      #### example

      - group agprop -n footest1 -v key5=val5

   7. ### dgprop : DEL_GROUP_PROP

      This function removes one or more properties from an existing LDAP group.

      #### required parameters

      - n : name - contains the name of an existing LDAP group.
      - v : properties * - multi-occurring property key and values are separated with a '='. e.g. mykey1=myvalue1

      #### example

      - group dgprop -n footest1 -v key5=val5

   8. ### rgroup : READ_GROUP

      This function reads and displays to console an existing LDAP group. The Group name is not case sensitive.

      #### required parameters

      - n : name - contains the full name for already existing Group

      #### example

      - group fgroup -n footest1

   9. ### fgroup : FIND_GROUPS

      This function searches and displays to console existing LDAP groups found as target of search. The Group name is not case sensitive.

      #### required parameters

      - n : name - contains the full name for already existing Group

      #### example

      - group fgroup -n fo

5. ### System Commands

   1. ### createsession : CREATE_SESSION

      #### required parameters

      #### optional parameters

      #### example

   2. ### authenticate : AUTHENTICATE

      #### required parameters

      #### optional parameters

      #### example

   3. ### assignedroles : ASSIGNED_ROLES

      #### required parameters

      #### optional parameters

      #### example

   4. ### checkaccess : CHECK_ACCESS

      #### required parameters

      #### optional parameters

      #### example

The org.apache.directory.fortress.cli.CommandLineInterpreter drives the Fortress APIs. For more info on how the Fortress APIs work, check out Fortress SDK Javadoc.