Using ACL

[sherihan]

Hi,
I've been trying to use Acegi ACL security but I got totally confused.
The ACL part in both acegi reference and spring in action is not clear enough(at least for me).
I already used acegi security for authentication and securing web requests and it's working fine.
But now I'm trying to use ACL to secure domain objects buI can't.

Here is a discription of my case. Hope someone could help me.

My application is so simple, it'a time attendance application.

I have 2 classe: Employee (which holds the employee data)
and Span (which holds the attendance information of the employees).

I have two types of employees (normal employees and managers).
Managers have more authorities than employees.
I have two ROLES in my application (ROLE_EMPLOYEE and ROLE_MANAGER).

The problem is:
I want to let each manager view the attendance information of a certain group of employees (the employees who work under his authority).

I don't want employees to see each other's data.

An employee can only view his own data.

A general manager can view the data of all employees and managers.

My classes are:
Employee:

private Long id;
	private String firstName;
	private String lastName;
	private String userName;
	private String secret;
	private Integer code;
	private String title;
	private Boolean isManager = new Boolean(false);

Span:

private Long id;
	private Employee employee;
	private String notes;
	private String ipAddress;

	private Date theDayDate;
	
	private Date startDate;
	private Date endDate;

	private Boolean isAuthorizable = new Boolean(false);
	private Date requestDate;
	private Date requestedStartDate;
	private Date requestedEndDate;
	
	private Employee manager;

My DataBase consists of the following tables:


Employee:

+-----------+------------------+------+-----+---------+----------------+
| Field     | Type             | Null | Key | Default | Extra          |
+-----------+------------------+------+-----+---------+----------------+
| id        | int(10) unsigned |      | PRI | NULL    | auto_increment |
| title     | varchar(20)      | YES  |     | NULL    |                |
| firstName | varchar(100)     | YES  | MUL | NULL    |                |
| lastName  | varchar(100)     | YES  |     | NULL    |                |
| code      | int(10) unsigned |      | UNI | 0       |                |
| isManager | tinyint(1)       | YES  |     | NULL    |                |
| userName  | varchar(255)     |      | MUL |         |                |
| secret    | varchar(255)     |      |     |         |                |
+-----------+------------------+------+-----+---------+----------------+

Span:

+--------------------+------------------+------+-----+------------+----------------+
| Field              | Type             | Null | Key | Default    | Extra          |
+--------------------+------------------+------+-----+------------+----------------+
| id                 | int(10) unsigned |      | PRI | NULL       | auto_increment |
| employee           | int(10) unsigned |      | MUL | 0          |                |
| manager            | int(10) unsigned | YES  | MUL | NULL       |                |
| isAuthorizable     | tinyint(1)       |      |     | 0          |                |
| theDayDate         | date             |      |     | 0000-00-00 |                |
| startDate          | datetime         | YES  |     | NULL       |                |
| endDate            | datetime         | YES  |     | NULL       |                |
| requestedStartDate | datetime         | YES  |     | NULL       |                |
| requestedEndDate   | datetime         | YES  |     | NULL       |                |
| requestDate        | datetime         | YES  |     | NULL       |                |
| notes              | varchar(255)     | YES  |     | NULL       |                |
| ipAddress          | varchar(255)     | YES  |     | NULL       |                |
+--------------------+------------------+------+-----+------------+----------------+

Employee Privileges:

+-----------+--------------+------+-----+---------+-------+
| Field     | Type         | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| userName  | varchar(255) |      |     |         |       |
| privilege | varchar(255) |      |     |         |       |
+-----------+--------------+------+-----+---------+-------+

Sorry for this long message.
Hope someone could help me.
Thanks in Advance.
Sherihan.

[Ben Alex]

I'd introduce a Department object that contains parentDepartmentepartment.

Each Employee belongs to one Department. Managers are employees as well, but there is nothing in the domain model to reflect them.

An Acegi Security acl_object_identity exists for every Department. Each Department has as its acl_object_identity.parent_object the appropriate parent Department. The top-level Departments share a mock Root object for its parent. Of course, each Employee also has an entry in acl_object_identity and for Employee objects the acl_object_identity.parent_object is the corresponding Department.

All that is then left to do is assign Employees with special management privileges rights to the appropriate Department. Your general manager and senior managers can be assigned rights (via acl_permission) to the correct Department they manage (the General Manager and System Adminsitrator will probably have rights against your Root acl_object_identity). Those rights flow down to include all employees in those Departments and sub-Departments. For Employees, just give them an acl_permission to their own record.

No ROLEs would be required for this setup.

The benefits of this model are (i) any number of levels of Department hierarchy can be established; (ii) there are minimal direct permisisons in acl_permission; (iii) Employees can be assigned privileges to selected other Employees, such as if needed for administrative assistants to enter time for their department members etc.

[eisenb]

I've been trying to wrap my head around the subject of ACLs. Between this post and the documentation, I'm still not getting it.

In looking at the diagram on p. 53 of the 0.81 docbook, I cannot quite decipher what is going on with the instances. There are sometimes two lines for each instance and references to parents which are not obvious. I think if I could see some sort of instantiation diagram, I might get the ACL parent inheritance concept a bit better.

I would like some more elaboration on the "mock Root object" that was referred to in the previous reply. I'm trying to figure out if I need to have mock objects within any of my stuff to facilitate ACLs.

In my own scenario, I have a catalog of things which users will possibly have read rights to. I also have contributors who have read / write privileges. And finally, administrators have full CRUD privileges.

Further, my catalog wraps categories which in turn contain items. It sounds like ACLs under this scenario could exist for the full catalog and for each item. Categories serve only organizational purposes and have no relevance for privileges. In this scenario, what might my ACL scheme be?

Sorry for the long and winding question. Apparently, the docbook isn't clear enough for those of us without much ACL implementation experience.

Bill

[dreed]

Hi Bill:

If I understand Ben's explanation correctly, the notion of a "root" user is neccersary because top level objects, say managers, at the top of the ACL food chain need to have a common parent. Because no objects are higher in the ACL hierarchy than managers, you need to create a ROOT department which acts as the parent of all supervisors. No user object would be assigned the root department. If you use ACL inheritance, all objects in a chain must have a parent, except for the top level object (essentially you can't have breaks in the chain, which is logical). The root department allows multiple managers to share in the same ACL hierarchy.

In terms of your application you could use inheritance or you could manually assign permissions each time an item is submitted (i.e., assign current user read/write, iterate through all admins and assign read/write/delete/administer). Inheritance is the more elegant way I think. Have you looked at the sample app that ships with Acegi? It is very helpful in understanding how ACL works.

HTH,

Dave

[Ben Alex]

Bil kindly contributed an ACL instantiation diagram that is now included in the DocBook.