PacketFence - BTS - PacketFence
View Issue Details
0000965PacketFenceweb adminpublic2010-04-19 18:522011-01-26 15:38
rdanielli 
obilodeau 
normalfeaturehave not tried
closedfixed 
1.8.7 
1.9.11.9.1 
ede8be2323f45d3c308e6a91bed0b19f11e8e1a5
0000965: Admin Portal - Granular Access Control
I had a client request that for their PF installation that some staff only have access to certain areas of the Admin portal.

The Network administrator desired total access for their staff. And, that help-desk staff only need access to the Node pages to register company laptops and and deal with daily operational issues.


Richard Danielli
President, eSubnet
We accomplished this task with only a minor change to a single PF file. This solution uses 3 files (which I have attached as a single text file).
  admin.perm - CSV list of admin-user and page permission values
  adminperm.inc - PHP include that checks permissions after the header.php loads
  header.php - original PF PHP file (we added 36 characters)

A couple of operations notes
- Permission is granted based on the admin-user having a permission value greater then that of the page.
- We used 1-5 for our permission values but you can set anything you like to increase flexibility.
- If an admin-user clicks on a page for which the are not allow they are returned to their default view
- If an admin-user is not listed in the permission file they are told this and logged out.
- We have not in anyway tried to get the 2 new files into the db.
- We have a loud for a group of admin-users to share a common name and permission level. The file adminperm.inc provides for a deliminator setting so that users like staff-1 and staff-2 only need to be referenced as staff-.
No tags attached.
txt PF-ADMIN_ACL.txt (3,090) 2010-04-19 18:52
https://www.packetfence.org/bugs/file_download.php?file_id=55&type=bug
Issue History
2010-04-19 18:52rdanielliNew Issue
2010-04-19 18:52rdanielliFile Added: PF-ADMIN_ACL.txt
2010-04-21 09:47obilodeauStatusnew => assigned
2010-04-21 09:47obilodeauAssigned To => obilodeau
2010-04-21 10:17rdanielliNote Added: 0001519
2010-04-21 10:39obilodeauNote Added: 0001520
2010-04-21 10:40obilodeauNote Added: 0001521
2010-04-21 10:40obilodeauSeveritytweak => feature
2010-04-21 10:40obilodeauCategorysecurity => web admin
2010-04-21 10:40obilodeauTarget Version => 1.9.0
2010-05-04 18:00obilodeauNote Added: 0001541
2010-05-04 18:00obilodeauTarget Version1.9.0 => 1.9.1
2010-07-27 12:36obilodeauNote Added: 0001615
2010-07-27 12:37obilodeauNote Edited: 0001615
2010-08-05 10:20obilodeaumtn revision => ede8be2323f45d3c308e6a91bed0b19f11e8e1a5
2010-08-05 10:20obilodeauNote Added: 0001626
2010-08-05 10:20obilodeauStatusassigned => resolved
2010-08-05 10:20obilodeauFixed in Version => 1.9.1
2010-08-05 10:20obilodeauResolutionopen => fixed
2011-01-26 15:38obilodeauStatusresolved => closed

Notes
(0001519)
rdanielli   
2010-04-21 10:17   
Please note as pointed out by my guy Kevin,

I did a renaming of the files and forgot to update the line in the header.php snippet I presented

:(
my bad
(0001520)
obilodeau   
2010-04-21 10:39   
This is a solid demonstration of granular access control done easily. This was requested several times without anyone willing to pay for it. Thanks a lot for sharing!

I did a little review and we are aiming to merge it as is in the upcoming 1.10.x (or 1.9.1). 1.9.0 is almost out so it won't cut it.

Some remarks (for us for future work on it):
- Opening a file on each page hit, it should be cached in session on login instead
- No way to edit rights through web
- Not conforming to our usual ini-style config files
- Because it's done in header.php, can the security be circumvented if you already know the right POST or point directly to a popup URL?

Thanks again for sharing this with us! Follow this bug to be updated when the merge will be done.
(0001521)
obilodeau   
2010-04-21 10:40   
Category change because 'security' is to track security issues.
(0001541)
obilodeau   
2010-05-04 18:00   
As expected, we are in release mode for 1.9.0 and this will have to be merged later. Targeting for 1.9.1.
(0001615)
obilodeau   
2010-07-27 12:36   
(edited on: 2010-07-27 12:37)
Imported your contriubtion into public branch: org.packetfence.feature.granular-admin-access

http://mtn.inverse.ca [^]

and added a task list: feature.granular-admin-access.TODO

(0001626)
obilodeau   
2010-08-05 10:20   
Feature merged into 1.9 branch.

Following changes on top of your contribution were performed:
- got rid of the delimiter approach for a role approach instead
- using .ini style format instead of custom fileformat
- using php .ini parser instead of custom parser
- concept of a default role where a user with no entry will have the default role instead of being denied
- not parsing the perms file on each page hit, cached in session on login instead
- 'You don't have sufficient permissions' page instead of a redirect
- Popups are handled also (were not before, you could load them straight)
- Documentation in admin guide

Your contribution has been attribute in NEWS and will be in the release notes.

I will generate a snapshot release of 1.9.1 that will include all this pretty soon.