Skip navigation links

Package org.apache.directory.fortress.core.cli

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

See: Description

Package org.apache.directory.fortress.core.cli Description

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:

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 OpenLDAP 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 * - multi-occurring attribute maps to organizationalPerson telephoneNumber attribute
      • Y : mobiles * - multi-occurring attribute maps to INetOrgPerson mobile attribute
      • @ : emails * - multi-occurring attribute maps to INetOrgPerson mail attribute
      • > : address * - multi-occurring 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 seconds of session inactivity time allowed
      • v : properties * - multi-occurring attribute contains property key and values are separated with a ':'. e.g. mykey1:myvalue1
      • r : roles * - multi-occurring attribute contains the name of already existing role to assign to user
      • a : adminRoles * - multi-occurring 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 OpenLDAP 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 * - multi-occurring attribute maps to organizationalPerson telephoneNumber attribute
      • Y : mobiles * - multi-occurring attribute maps to INetOrgPerson mobile attribute
      • @ : emails * - multi-occurring attribute maps to INetOrgPerson mail attribute
      • > : address * - multi-occurring 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 seconds of session inactivity time allowed
      • v : properties * - multi-occurring attribute contains property key and values are separated with a ':'. e.g. mykey1:myvalue1
      • r : roles * - multi-occurring attribute contains the name of already existing role to assign to user
      • a : adminRoles * - multi-occurring 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

      OpenLDAP 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 OpenLDAP 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 * - multi-occurring 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 * - multi-occurring 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 * - 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 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 * - multi-occurring attribute used to set associations to existing PERMS OrgUnits
      • U : osUs * - multi-occurring 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 * - multi-occurring attribute used to set associations to existing PERMS OrgUnits
      • U : osUs * - multi-occurring 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 seconds 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. \
    6. 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
    7. 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
    8. 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
    9. 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
    10. 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
    11. 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
    12. 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
    13. 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
    14. 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
    15. 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
    16. 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
    17. 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
    18. 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
    19. 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
    20. 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
    21. 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
    22. 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
    23. 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
    24. 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
    25. 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
    26. 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 * - multi-occurring 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 * - multi-occurring 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 multi-occurring attributes.

      required parameters

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

      optional parameters

      • M : members * - multi-occurring 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 * - multi-occurring 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 * - multi-occurring 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.

Skip navigation links

Copyright © 2003-2016, The Apache Software Foundation. All Rights Reserved. Generated 20160718-1619