[Kolab-devel] Design and Development of a new Kolab Web Administration Panel

[Jeroen van Meeuwen (Kolab Systems)]

Hi there,

work has been started on the development of a new Kolab Web 
Administration Panel (or, lovingly, the KWAP), targeted for inclusion 
with Kolab 3.0, well, as soon as possible.

The first development milestone includes the following basic 
functionality:

   - Add/Edit/Remove Users
   - Add/Edit/Remove Groups
   - List/Search either.

As has been mentioned before, but deserves outlining again, the lower 
level design for the KWAP consists of two major components. One is the 
client "clickydiclick" web interface, and the other is an API backend.

This would enable other interfaces to execute Kolab Groupware tasks of 
an administrative nature, through what is supposed to become a stable 
API, such as for example GoSA, but customer-facing interfaces in Hosted 
scenarios as well. Additionally, we have some sort of a client 
command-line tool-chain coded against this.

Thomas Bruederli has kindly outlined an initial draft design[1] for 
communication with the API, which I've taken one step further in my 
attempt to document[2] my work[3].

Please read both [1] and the beginning few sections of [2] to get up to 
speed, if you need to, as the topics involve something that has been 
brewing over the past few weeks.

Noted that this is in the initial experimental development phase, 
suffice it to say the design is still subject to what we discover / 
think of attempting to implement said design.

[1] 
wiki.kolab.org/index.php?title=User:Bruederli/Draft:Kolab_Webadmin_API
[2] 
http://hosted.kolabsys.com/~vanmeeuwen/kolab-docs/en-US/Kolab_Groupware/2.4/html/Architecture_and_Design/sect-Architecture_and_Design-Administration_Panel-Web_Administration_Panel_API.html
[3] http://git.klab.cc/vanmeeuwen/kolab-wap/

= Question(s) of The Day =

== "system.capabilities" API call ==

First of all, our "system.capabilities" API call was designed to list 
the "services" and "methods" for those services, a logged in user is 
authorized to perform. For example, where I to log in as 'manager', I 
would get something like this:

   { 'status': 'OK', 'result': { 'user.add': 'w', 'user.delete': 'w', 
(...)} }

whereas, would I log in with a normal user account, I would get 
something more along the lines of:

   { 'status': 'OK': 'result': { 'user.info': 'r', 'user.find': 'r', 
(...)} }

Hoping that makes sense, we have ended up with the following problem:

In PHP, there's no existing mechanism to get the effective rights on a 
particular LDAP object, which would be needed in order to allow the API 
backend to detect whether or not the logged in user is allowed to add 
entries to, for example, ou=People,dc=klab,dc=cc - effectively being 
permitted to "user.add": "w" if you will.

An alternative approach needs to be designed.

== Plural vs. Singular Object Names ==

The concept of using object's names in singular or plural form to allow 
an API client's adaptive code to behave anticipatory (in terms of 
expecting results) has created a challenge in defining an approach to 
build the menu for the API client "clickydiclick" web interface.

While using only the plural *or* singular form of an object's name in 
the response to a "system.capabilities" API call and corresponding 
service names allows for simple grouping and building a menu like so:

On 2011-12-13 11:32, Jeroen van Meeuwen (Kolab Systems) wrote:
>
>   +- User      +- Group
>    `- Add       `- Add
>    `- Edit      `- Edit
>    `- List      `- List
>    `- Search    `- Search
>

With a mixture of plural and singular forms of an object's name in the 
response to a "system.capabilities" API call, a menu could be built 
using either variant of the following:

On 2011-12-13 11:32, Jeroen van Meeuwen (Kolab Systems) wrote:
> Alternatively though, one could opt for any of the following 
> structures as well;
>
>   +- User      +- Group     +- List       +- Search
>    `- Add       `- Add       `- Groups     `- Groups
>    `- Edit      `- Edit      `- Users      `- Users
>
> or;
>
>   +- Add       +- List           [   Search   ]+
>    `- Group     `- Groups           [ ] - Groups
>    `- User      `- Users            [ ] - Users
>
> You would get to edit from List/Search -> Info -> Edit/Delete, 'Add'
> is actually more of a "Quick Add", and Search is not unlike the 
> search
> box in a Roundcube mailbox view / addressbook.
>

The argument for a mixture of plural and singular forms of an object's 
name is very thin, namely; the result (set) to be expected by the client 
can be assumed to be 0 (singular, plural), 1 (singular, plural), or more 
(plural).

I don't think anyone really cares all that much, but I figured I'd 
include the Question of The Day here in the interest of full disclosure, 
and to hopefully find some genius insight with you.

== Authorization ==

While authorization is something we should make happen in the 
authentication and authorization database backend as much as possible 
(i.e. LDAP ACLs), "discovering" such authorization is particularly hard 
lacking getEffectiveRights controls in PHP. This largely impedes the API 
backend's capabilities to (quickly) come up with a list of services and 
corresponding methods a user is authorized to perform.

An alternative approach is to use a known, defined set of groups and/or 
roles, and recognize these in the API backend itself as authorized for a 
certain service method.

These groups and/or roles would be defined in LDAP, with ACLs allowing 
or denying them access where appropriate, and would be allowed to use 
uber-administrative credentials through authorization information stored 
in SQL (i.e. "bind as manager" instead of "bind as logged in user"). 
Something like a function "user_can" could take the service name, and 
method name, and return privileges based on 1) group membership / 2) SQL 
-perhaps.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08