Question

I’m trying to come up with a good way to do authentication and authorization. Here is what I have. Comments are welcome and what I am hoping for.

I have php on a mac server.
I have Microsoft AD for user accounts.

I am using LDAP to query the AD when the user logs in to the Intranet.

My design question concerns what to do with that AD information. It was suggested by a co-worker to use a naming convention in the AD to avoid an intermediary database. For example, I have a webpage, personnel_payroll.php. I get the url and with the URL and the AD user query the AD for the group personnel_payroll. If the logged in user is in that group they are authorized to view the page. I would have to have a group for every page or at least user domain users for the generic authentication.

It gets more tricky with controls on a page. For example, say there is a button on a page or a grid, only managers can see this. I would need personnel_payroll_myButton as a group in my AD. If the user is in that group, they get the button. I could have many groups if a page had several different levels of authorizations.

Yes, my AD would be huge, but if I don’t do this something else will, whether it is MySQL (or some other db), a text file, the httpd.conf, etc.

I would have a generic php funciton IsAuthorized for the various items that passes the url or control name and the authenticated user.

Is there something inherently wrong with using a naming convention for security like this and using the AD as that repository? I have to keep is somewhere. Why not AD?

Thank you for comments.

EDIT: Do you think this scheme would result in super slow pages because of the LDAP calls?

EDIT: I cannot be the first person to ever think of this. Any thoughts on this are appreciated.

EDIT: Thank you to everyone. I am sorry that I could not give you all more points for answering. I had to choose one.

Answer 1

I wonder if there might be a different way of expressing and storing the permissions that would work more cleanly and efficiently.

Most applications are divided into functional areas or roles, and permissions are assigned based on those [broad] areas, as opposed to per-page permissions. So for example, you might have permissions like:

• UseApplication
• CreateUser
• ResetOtherUserPassword
• ViewPayrollData
• ModifyPayrollData

Or with roles, you could have:

• ApplicationUser
• ApplicationAdmin
• PayrollAdmin

It is likely that the roles (and possibly the per-functionality permissions) may already map to data stored in Active Directory, such as existing AD Groups/Roles. And if it doesn’t, it will still be a lot easier to maintain than per-page permissions. The permissions can be maintained as user groups (a user is either in a group, so has the permission, or isn’t), or alternately as a custom attribute:

dn: cn=John Doe,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: webAppUser
cn: John Doe
givenName: John
...
myApplicationPermission: UseApplication
myApplicationPermission: ViewPayrollData

This has the advantage that the schema changes are minimal. If you use groups, AD (and every other LDAP server on the planet) already has that functionality, and if you use a custom attribute like this, only a single attribute (and presumably an objectClass, webAppUser in the above example) would need to be added.

Next, you need to decide how to use the data. One possibility would be to check the user’s permissions (find out what groups they are in, or what permissions they have been granted) when they log in and store them on the webserver-side in their session. This has the problem that permissions changes only take effect at user-login time and not immediately. If you don’t expect permissions to change very often (or while a user is concurrently using the system) this is probably a reasonable way to go. There are variations of this, such as reloading the user’s permissions after a certain amount of time has elapsed.

Another possibility, but with more serious (negative) performance implications is to check permissions as needed. In this case you end up hitting the AD server more frequently, causing increased load (both on the web server and AD server), increased network traffic, and higher latency/request times. But you can be sure that the permissions are always up-to-date.

If you still think that it would be useful to have individual pages and buttons names as part of the permissions check, you could have a global “map” of page/button => permission, and do all of your permissions lookups through that. Something (completely un-tested, and mostly pseudocode):

$permMap = array(
    "personnel_payroll" => "ViewPayroll",
    "personnel_payroll_myButton" => "EditPayroll",
    ...
);

function check_permission($elementName) {
    $permissionName = $permMap[$elementName];
    return isUserInLdapGroup($user,$permissionName);
}