Developer Reference > User Control Access Rights

Draft 3 (Final candidate)
Date: 17 Jan. 2001
Preface
This document is a draft for AOS UCAR implementation. It is going to be one of the API standard, where apply for all existing and future AOS and DA development.

A simple user privilege has been defined during the development on the storage system. And we felt that it is necessary to add more group and access control to AOS, for existing modules and future modules.
Future modules will have to build around with UCAR in mind, allowing the admin to drill down to the module access table, assigning property for each element of the module. For example, the admin may set property for file and folders of the storage system to block certain group of user access. The admin may create topics in the meeting section, set access right on each topic to allow only a predefined group of users to gain access.

AOS implemented both the “group” and “level” concept (refer as privileges, “priv” as follow) where:
Group = case insensitive, max 64 chars. min 1 chars, spaces allow, and full ASCII support - except:

• Quote (ASC 34),
• DEL (ASC 8),
• CR (ASC 13) and
• LF (ASC 10).

Eg: “Admin” and “User” on the system default.
VO account default to have the following groups:

1. Admin
2. User
3. Guest
4. Sale
5. Account
6. Management

Admin may add more.

Level = integer starting from 1. There are no up bound limit. AOS reserved 0 and all negative values.

• each object has a default priv when created (menu, folder, meeting topic, discussion topic, user)
• for legacy objects, the default group will be “User”, level 10
• object may contains no priv property, but inherit from the parent object (email, files, note item)
• each object may contains multiple group definition, but only a level definition allow.
• access granted once group are matched (level are ignored in this case)
• lower level overwrite higher level and groups, e.g.: level 2 may access level 3 objects, even if both objects are not in the same group.
• equal level relay on group for access, e.g.: level 3 cannot access level 3 objects if both objects group are different.
• level is in consideration only when group is not matched.

Suggested UCAR checking flow

Comparison table of UCAR:

Level 0 is reserved for AOS controller, where carry the highest access priv to all objects.
Some objects priv may be set by the system admin only (group “Admin”, level 1), like the Menu item or user priv.
However, many of the object priv can be changed by users with the following rules:

• object level cannot be changed to the level lower then the user
• object group cannot be changed/added to the group other than the group assigned with the user (except for user on level 1)
• object may allow dual definition for access and control. E.g.: an object may be defined to allow access from level 3, but only allow users on level 2 to make priv changes. It is up to the DA developer to decide on the internal architecture.

LiangTyan Fui
Primary Draft 1, 6 Aug. 2000
Draft 2, 9 Aug. 2000 Final Candidate: 17 Jan. 2001