Auth library - request for comments

import

--=_mixed 00540DEBC1256ED3_=
Content-Type: multipart/alternative; boundary="=_alternative 00540DEBC1256ED3_="

--=_alternative 00540DEBC1256ED3_=
Content-Type: text/plain; charset="us-ascii"

Hi,

It might also be useful for the Campsite developers to be aware of the
components that are being developed for the LiveSupport project, which are
intended as PHP PEAR modules. Micz has written to the campsite-dev list
previously about the auth module serving as the base for any CMS work we
do in the future, and I agree with that approach. So, in that spirit, here
are the relevant modules coming from the Green Box/Live Support projects.

- Authentication, which handles which users and groups can do.
- Workflow, which determines what happens to objects when a user works on
them
- File archive, which stores metadata describing an object (in this
instance a sound file, but other objects are supported) as well as a
pointer to object on the file system. The file archive module replaces the
MMA multimedia archive, which proved to be too difficult and unwieldy to
use for this purpose.
- File transfer, which governs upload and download of objects
- HTML GUI interfaces to these modules

We are planning an API which will allow Campsite (the pre-3.0 C++ version,
I presume) to use the file archive system either instead of or in
addition to the MySQL database. This part is still fuzzy, and it would be
good if Tomas Hlava, the developer of these modules, got together with the
Campsite developers to work on this a bit more.

I'm including Tomas' RFC for the auth module, which is already written and
will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be
forwarded to the Campsite-dev list as we get them done.

doug

--=_alternative 00540DEBC1256ED3_=
Content-Type: text/html; charset="us-ascii"

Hi,

It might also be useful for the Campsite developers to be aware of the components that are being developed for the LiveSupport project, which are intended as PHP PEAR modules. Micz has written to the campsite-dev list previously about the auth module serving as the base for any CMS work we do in the future, and I agree with that approach. So, in that spirit, here are the relevant modules coming from the Green Box/Live Support projects.

- Authentication, which handles which users and groups can do.

- Workflow, which determines what happens to objects when a user works on them

- File archive, which stores metadata describing an object (in this instance a sound file, but other objects are supported) as well as a pointer to object on the file system. The file archive module replaces the MMA multimedia archive, which proved to be too difficult and unwieldy to use for this purpose.

- File transfer, which governs upload and download of objects

- HTML GUI interfaces to these modules

We are planning an API which will allow Campsite (the pre-3.0 C++ version, I presume) to use the file archive system either instead of or in addition to the MySQL database. This part is still fuzzy, and it would be good if Tomas Hlava, the developer of these modules, got together with the Campsite developers to work on this a bit more.

I'm including Tomas' RFC for the auth module, which is already written and will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be forwarded to the Campsite-dev list as we get them done.

doug

--=_alternative 00540DEBC1256ED3_=--

--=_mixed 00540DEBC1256ED3_=
Content-type: message/external-body; access-type=URL; URL=http://sympa.mdlf.org/sympa-bin/wwsympa.fcgi/attach/campsite-dev/OFA0B612F8.F3B61C03-ONC1256ED3.0052B57E-C1256ED3.00540DF4@mdlf.org/aarfc_html; name="aarfc_html"; size="9986"

Content-type: text/html; name="aarfc.html"
Content-Transfer-Encoding: base64

--=_mixed 00540DEBC1256ED3_=--

------------------------------------------
Posted to Phorum via PhorumMail

import

--0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5
Content-type: text/plain; charset=us-ascii

Please take these into consideration when thinking about CMF versus Pear
etc.

Best,

Sava

Douglas.Arellane
s@mdlf.org To: campsite-dev@campware.org
cc:
07/16/04 05:18 Subject: [campsite-dev] Components from LiveSupport
PM
Please respond
to campsite-dev

Hi,

It might also be useful for the Campsite developers to be aware of the
components that are being developed for the LiveSupport project, which are
intended as PHP PEAR modules. Micz has written to the campsite-dev list
previously about the auth module serving as the base for any CMS work we do
in the future, and I agree with that approach. So, in that spirit, here are
the relevant modules coming from the Green Box/Live Support projects.

- Authentication, which handles which users and groups can do.
- Workflow, which determines what happens to objects when a user works on
them
- File archive, which stores metadata describing an object (in this
instance a sound file, but other objects are supported) as well as a
pointer to object on the file system. The file archive module replaces the
MMA multimedia archive, which proved to be too difficult and unwieldy to
use for this purpose.
- File transfer, which governs upload and download of objects
- HTML GUI interfaces to these modules

We are planning an API which will allow Campsite (the pre-3.0 C++ version,
I presume) to use the file archive system either instead of or in addition
to the MySQL database. This part is still fuzzy, and it would be good if
Tomas Hlava, the developer of these modules, got together with the Campsite
developers to work on this a bit more.

I'm including Tomas' RFC for the auth module, which is already written and
will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be
forwarded to the Campsite-dev list as we get them done.

doug

(See attached file: aarfc.html)

--0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5
Content-type: message/external-body; access-type=URL; URL=http://sympa.mdlf.org/sympa-bin/wwsympa.fcgi/attach/campsite-dev/OF60F13D90.0B52D90D-ONC1256ED3.00548135-C1256ED3.0054D550@mdlf.org/aarfc_html; name="aarfc_html"; size="9986"

Content-type: text/html;
name="aarfc.html"
Content-Transfer-Encoding: base64

--0__=4EBBE440DFC707A58f9e8a93df938690918c4EBBE440DFC707A5--

------------------------------------------
Posted to Phorum via PhorumMail

import

As far as I can tell, and unless I am missing something, the PEAR
argument is code words for "building it from scratch". As you can see
here: http://seagull.phpkitchen.com/?ref=sf#api , any decent CMS will
be built on top of PEAR. But nothing in PEAR has anything close to the
functionality of a full CMS.

sava.tatic@mdlf.org wrote:

cite="midOF60F13D90.0B52D90D-ONC1256ED3.00548135-C1256ED3.0054D550@mdlf.org"
type="cite">

Please take these into consideration when thinking about CMF versus Pear

etc.



Best,



Sava





                                                                                                                                   

                      Douglas.Arellane                                                                                             

                      s@mdlf.org               To:      campsite-dev@campware.org                                                  

                                               cc:                                                                                 

                      07/16/04 05:18           Subject: [campsite-dev] Components from LiveSupport                                 

                      PM                                                                                                           

                      Please respond                                                                                               

                      to campsite-dev                                                                                              

                                                                                                                                   

                                                                                                                                   











Hi,



It might also be useful for the Campsite developers to be aware of the

components that are being developed for the LiveSupport project, which are

intended as PHP PEAR modules. Micz has written to the campsite-dev list

previously about the auth module serving as the base for any CMS work we do

in the future, and I agree with that approach. So, in that spirit, here are

the relevant modules coming from the Green Box/Live Support projects.



- Authentication, which handles which users and groups can do.

- Workflow, which determines what happens to objects when a user works on

them

- File archive, which stores metadata describing an object (in this

instance a sound file, but other objects are supported) as well as a

pointer to object on the file system. The file archive module replaces the

MMA multimedia archive, which proved to be too difficult and unwieldy to

use for this purpose.

- File transfer, which governs upload and download of objects

- HTML GUI interfaces to these modules



We are planning an API which will allow Campsite (the pre-3.0 C++ version,

I presume)  to use the file archive system either instead of or in addition

to the MySQL database. This part is still fuzzy, and it would be good if

Tomas Hlava, the developer of these modules, got together with the Campsite

developers to work on this a bit more.



I'm including Tomas' RFC for the auth module, which is already written and

will be up on the LiveSupport CVS soon, hopefully. Other RFCs will be

forwarded to the Campsite-dev list as we get them done.



doug







(See attached file: aarfc.html)

Auth library

Auth library - request for comments

Version: 0.1 - the first draft - 28.2.2004, 2.3.2004

Authentication & authorization

Authentication - as user's identity
checking - would be done using PHP session management after user's
successful login with username/password or XML/HTTP login have been
done by external application.

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

Basic model

Subject --- Action ---> Object

Where:

Subject

is subset from table of users - one user or user group

[or - optional - general select from user table (with general
condition)]

Action

is one or more records from predefined action table (selection depends
on object type)

Object

is a item from object table - specified by class and identification
within the class

Subject implementation

Subjects would be simply implemented by table of users, table of
groups and many2many relation between users and groups (auxiliary
table => user may be member of several groups).

Data may be loaded from existing application.

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.

Each object type would be also represented by "object class", which
have to be registered by application - e.g. provide set of allowable
actions.

Example:

RootNode

        |

        |-> PublicationA

        |              \-> Issue1

        |                       |-> Section(type=sport)       <--\

        |                       \-> Section(type=politics)       |

        |-> PublicationB                                         |

        |              |-> Issue1                                |

        |              |        |-> Section(type=politics)       |

        |              |        |-> Section(type=sport)       <--|

        |              |        \-> Section(type=culture)        |

        |              \-> Issue2                                |

        |                       |-> Section(type=culture)        |

        |                       \-> Section(type=politics)       |

        |                   ^                                    |

        |-> IssueGroup------/ (no condition - all Issues)        |

        |                                                        |

        \-> SectionGroup(type="sport")---------------------------/

Object table definition:

[id, description,

class, id_within_class]

and tree description table:

[obj1_id, type_of_relation, obj2_id
 class="b">]

Types of relation: is_child_of, is_member_of etc...

Class used in example:

Publication, Issue, Section, IssueGroup,

SectionGroup

Privileges for actions

There are several ways to handle privileges - I consider this two:

only allow - more simple method - all without
allow privilege is denied.

or allow/deny - less simple - all without allow
privilege is denied, but more specified setting may overcome less
specified

(e.g. group of users is allowed, but one specified group-member is
denied)

Privileges would be stored as triple class="b">[subject, action, object]
and allow/deny flag (if is used).

rem.: Type of subject (user or group) should be included somewhere.

Procedure of privilege checking:

If exists deny privilege on corresponding object
for user => DENY

If exists allow privilege on corresponding object
for some user's group => ALLOW

If exists allow privilege on corresponding object
for user => ALLOW

otherwise DENY

Simple objects (e.g.Section) may belong to more complex objects
(e.g.SectionGroup) - system should first look for privileges associated
with simple object and then - if nothing found - search privileges on
complex objects and go up in the tree for inherited privileges.

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

Example:

Privileges:

 [$admin_id,   allPriv,   $RootNode_id,   allow[$GroupA_id,   writePriv,   $SectionGroupSport_id,   allow[$userB_id,   writePriv,   $PublA_Issue1_SectionSport_id,   deny[$userC_id,   addChildPriv,   $PublicationA_id,   allow

Objects:

 [$RootNode_id,   'RootNode',   'RootNode',   ''[$PublA_Issue1_SectionSport_id,   'PublA/Issue1/SectionSport',   'Section',   'id=$id_in_sections_table'[$SectionGroupSport_id,   'SectionGroupSport',   'SectionGroup',   'type="sport"'[$PublicationA_id,   'PublicationA',   'Publication',   'id=$id_in_publications_table'

Auth system usage

There are 3 main types of usage:

authorization of called action

automatic modification of user interface in dependence on user
privileges

automatic generation of admin interface for privileges settings

Important part of API

(Real code should be OO - set of classes with methods.)

int initObjectTree()

int addObjectTreeNode(parentNode, description, class, identification)

method for object-tree building

int registerClass(className, properties)

I think, it will be needed

int login(userName, password)

int logout(userName, password)

int getPrivilege(user, action, object)

would be used for every called actions. (usage type 1.)

int setPrivilege(user, action, object)

would be called from admin interface

xml getTopLevelEditableObjects(subject)

in example above provides list of high level items, where user have
some editation privileges

(usage type 2.)

xml getAdminUI(startNodeId=<RootNodeId>, subject)

for default RootNode provides list of publications with editation
elements,

for startNode pointing to 'PublicationB/Issue2' provides list of
Sections etc...

(usage type 3.)

addUser(), addGroup(), addUser2Group() ...

Connection to existing applications

PHP applications may include this library and call API functions
directly.

Other programming platforms may call XML/HTTP layer above API
functions.

Applications should be responsible for object tree generation and
modification by calling API.

(e.g. when application provides "Add new issue")

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

------------------------------------------
Posted to Phorum via PhorumMail

Auth library - request for comments

Authentication & authorization

Basic model

Subject implementation

Object implementation

Example:

Privileges for actions

Example:

Auth system usage

Important part of API

Connection to existing applications

Howdy, Stranger!

Categories

Poll

Top Posters