Auth library - request for comments

22.7.2004

Authentication & authorization

Authentication - as user's identity checking - login call create and return auth token, client sends this token with all subsequent calls, logout call make this token invalid

Authorization - as checking user's permission for called action on some object - that's main solved problem.

Basic model

Subject --- Action ---> Object

Where:

Subject implementation

Subjects are divided into two types - users and groups. There is membership relation (type N:M) from subjects table to itself with "linearization" feature - for questions about it send me a mail please ;)
This approach allows inserting user to group or group to group with quick searching of direct and indirect membership.

Object implementation

For simple use with existing projects, there would be a object tree always separated from project's database tables. It would be implemented by table of objects and information about parent/child (or other) relation between objects.

There is also class table and N:M membership relation between objects and classes.

Example:

RootNode
        |
        |-> Publication_A(publication)
        |              \-> Issue_1(issue)              <--\
        |                       |-> Sport(section)        |    <--\
        |                       \-> Politics(section)     |       |
        \-> Publication_B(publication)                    |       |
                       |-> Issue_1(issue)              <--|       |
                       |        |-> Politics(section)     |       |
                       |        |-> Sport(section)        |    <--|
                       |        \-> Culture(section)      |       |
                       \-> Issue_2(issue)              <--|       |
                                |-> Culture(section)      |       |
                                \-> Politics(section)     |       |
                                                          |       |
Class "Issues" -------------------------------------------/       |
Class "Sport sections" -------------------------------------------/

Permissions for actions

There are several ways to handle permissions - I've used this:
allow/deny - all without allow permission is denied, but more specified setting may overcome less specified
(e.g. group of users is allowed to do smth., but one specified group-member is denied)

Permissions are stored as triple [subject, action, object] and allow/deny flag.

Procedure of permission checking:

Rem.: Some cache system for authorization decisions would be good ...

Auth system usage

There are 3 main types of usage:

  1. authorization of called action
  2. automatic modification of user interface in dependence on user permissions
  3. automatic generation of admin interface for permissions settings

Important part of API:

All methods may return PEAR::error object if fails ...

Connection to existing applications

PHP applications could include Alib class and call API methods directly.
Other programming platforms should call XMLRPC or HTTP layer above this API.


P.S.: sorry for my English ... ;)