Introduction to LiveUser
LiveUser in short...
PEAR::LiveUser is a framework aimed at dealing with authentication and permission management.
The PEAR::Liveuser_Admin packages will help you manage users, groups, and rights.
Authentication is the process of identifying an individual, based on a username and a password. The authentication process helps ensuring you know who is connected.
This is different from permission (or authorization) which is a right to access a system or part of a system. This ensures, for instance, that only authorized persons can access the accounting system and view client invoices.
Altough LiveUser is still in a beta version, it's sufficiently stable to already be used in production.
As some other, we missed some detailed documentation. It took us some time to dig into it. Now that we understand it enough to have my requirements met, we propose to share our experience with you.
Any feedback/comment is welcome and can be sent to us.
If you only need authentication and no permission management, you may consider using PEAR::Auth as an authentication system. It's easy to start with and works fine.
The first point of reference is the PEAR site.
You may find more advanced help by visiting the PEAR forum. Although most messages are in German, you may write in English as well or use the build-in translation feature. People there are very responsive and really kind.
Behind the scene
LiveUser allows you to use several authentication sources at once. This may prove usefull if you have your company users stored in one datasource and some clients stored in another datasource and they all need to connect to your system.
Please note that LiveUser supports various authentication sources such as XML or database. Refer to the original documentation for a full list. We'll look at a link to a mySQL database thru 2 different containers (PEAR::DB and PEAR::MDB2).
Lets start with an example, that will illustrate some of the LiveUser features.
On the WiKi, Örjan Persson provided an illustration of the LiveUser key elements:
- groups and sub-groups
Applications can be divided into areas. For instance, the order management area, the news management area, ...
Each area may be granted some dedicated access rights. Example: the order management may have restricted access right so that not every Internet user may see the list of pending orders. People managing effectively orders will be granted a full access to this area. Managers may view the order data but not modify it.
Having been granted some access right may imply getting automatically another access right (example: the user who may modify some data will also probably be allowed to view the same data).
Users may be member of a sub-group, themselves organised into imbricated groups.
Users may be granted access directly or thru a (sub-)group membership.
These LiveUser elements are mapped to a series of database tables:
Get in touch!
We'd love to hear from you, what you think about this page or what we can do for you.Contact Us