Let’s assume that the Zend ACL is in a custom library that is loaded in the constructor of a controller that requires authorization. Taking a simple example of authorizing based on the controller, within the ACL library you could check authorization like so:
I looked at the ZendACL and I like what I see. The only issue I have in using it is that it would require loading other Zend framework libraries that replicate CI functionality i.e. the database library would be needed and so my application would need to load both CI and Zend dbi’s. I guess I could build an interface between the CI dbi and ZendACL/Auth libs. Zend does offer fine control over access to assets (resources)...
Yes, I will need an admin function that allows roles and resources to be crud. I found a podcast on PHP Abstract that talks about the zend ACL. The only dependencies I’ve found so far is on the Zend Exception class… I prefere db storage and would like to encrypt the serialized data for security sake. After all, this is a global ACL and if it got leaked, you would loose all control. Have any suggestions on how best to do that?
I probably don’t understand your concern, but even if someone had access to your server and could look at the ACL, what harm would that do? It is more important to protect usernames/passwords. I think that if a stranger could access your server, then you have larger concerns.
Sorry, I think I understand now. You want to serialize the ACL object and store it in the database. In which case, if someone could access your database, they could transparently change the ACL to grant a user admin privileges for example. That would be a problem since you might not know about it. So I guess if the serialized ACL is a string, you could use the CI encryption library when getting/saving the ACL to the database.
Sorry for late reply but yes, my concern is if someone accessed the acl they could alter it. Encrypting it would solve this issue or at least make it much more difficult to alter the acl in the database. This is also why I seed passwords with extra characters before encrypting them with MD5 or SHA1. Both can be broken. In fact I once saw a demo of an MD5 hash broken on a laptop PC in less than an hour. The issue with MD5 is that collisions can happen in the hash. In other-words, two very different passwords can result in the same MD5 hash. MD5 was an improvement on MD4 but only decreases the odds of a collision and with pc’s gaining more processing power every few months, the MD5 hash simply is not tight enough alone. Many once secure hashing methods simply have become less secure becuase the processing power of pc’s has increase beyond what was expected when the algorythm was designed. Security is always a major concern for me.
Spotted this a few minutes ago and it may apply to earlier messages in reference to Zend_ACL and storing ACL infomation in a database. It’s an extension to Zend_ACL posted on phpclasses.org. Have not looked at this, but the description seemed to apply.
a) As mentioned above it would load it’s own libraries, which means more resources/time overhead.
Zend Framework components were designed to be isolated from one another. The acl component doesn’t rely on any other framework component (except the zend_exception class which can be changed to the native exception with a search/replace).
If using Adodb for database abstraction is not a problem, you can use phpGACL. If you go that route, use the updated Adodb integration instructions at CiForge rather than the wiki instructions. It should be possible to convert phpGACL to use the CI DBAL with a bit of work.
There is a RBAC solution on sqlrecipes.com. Download instructions are mentioned in the comments on the article that discusses the solution.