Version 26 (modified by Dominic König, 13 years ago) ( diff )


DeveloperGuidelinesS3Framework | S3AAA

S3 Authentication, Authorization and Accounting

Authentication is the act of establishing or confirming someone's identity.
Authorization is the concept of allowing access to resources only to those permitted to use them.
Accounting refers to the tracking of user actions - an audit trail.


AAA functions for S3 are implemented in the modules/s3/ module. This module extends the web2py Auth class as AuthS3 (Authentication), and defines additional classes for role management, access control and audit.

AuthS3modules/s3/s3aaa.pyAuthentication, Login
S3Permissionmodules/s3/s3aaa.pyAuthorization of Access, ACLs
S3Auditmodules/s3/s3aaa.pyData access logging, audit trail
S3RoleManagermodules/s3/s3aaa.pyRESTful method to manage roles and ACLs
Admin controllerscontrollers/admin.pyUser Management, role management


Current user

Interactive Login

HTTP Basic Authentication


Roles are defined in the auth_group table, which is defined by the AuthS3 module (in modules/s3/
Each role as an ID, a unique name and an optional description.

Access permissions are granted to roles, while a user gets permissions by assigning roles to him. Role assignment is stored in the auth_membership table, which is defined by the AuthS3 class (in modules/s3/

At the start of every request, the IDs of all roles of the currently logged-in user are stored as list in session.s3.roles (in models/ In cases where the user is logged-in during the request (e.g. by HTTP Basic Auth), a refresh of this list is also triggered by the login_bare() method of AuthS3.

Roles can be managed in the S3RoleManager interface (Administration => User Management => Roles).

The following roles are pre-defined in S3 and cannot be changed:

1Administratorsystem administrator
2Authenticatedall authenticated users
3Creatorcurrently unused
4Editordata editor

The first registered user gets the Administrator role assigned.
Users with the Administrator role always have all permissions, and may access all pages in Eden. The Administrator may also manage Users, Roles and ACLs.

Users with the Editor role may access all data with all methods, except they can not manage Users, Roles or ACLs.

Every authenticated user gets automatically the Authenticated role assigned. This role assignment cannot be revoked.

Simple Authorization

Simple authorization means, that

  • anonymous users have read-only permission
  • authenticated users have full access
  • the Administrator may additionally access the user management

This is the fallback model wherever there are no ACLs defined.


Access Control Lists (ACLs) are bit arrays with each bit representing a permissions to access data with a particular method:

auth.permission.CREATE0x01may create new records
auth.permission.READ0x02may read or list records
auth.permission.UPDATE0x04may update existing records
auth.permission.DELETE0x08may delete records

ACLs are combinations of these bits (by logical OR), e.g. an ACL with the value 0x06 defines permissions to read and update records, while no permission to add or to delete any records.

ACLs are stored per role and request destination in the s3_permission table, which is defined by the S3Permission class (in modules/s3/

For every destination (controller/function/table) two ACLs can be defined to be applied depending on whether a user ownes the record or not:

  • one ACL for users owning a record (Owner ACL = oacl)
  • one ACL for any other user not owning the record (User ACL = uacl).

If a user ownes a record, then the most permissive of the User ACL and the Owner ACL gets applied, otherwise only the User ACL gets applied.

Record Ownership

Tables can implement a record ownership by adding two meta fields:

Field nameTypeDescription
created_byinteger (reference auth_user)ID of the user who has created this record
owned_byinteger (reference auth_group)ID of the group (role) who own the record

These meta fields are contained in both s3_authorstamp() as well as s3_meta_fields().

A user is considered owner of a record if he has either created the record (user ID == created_by), or he is a member of the owner group (owned_by in user roles).

In tables which do not define either of these meta-fields, ownership rules are not applied (uacl only).

Controller/Table Restriction

ACLs can be defined for controllers, and for particular functions inside controllers.
ACLs can additionally be defined for individual database tables.

The controller ACLs are activated by setting the respective controller to restricted=True in deployment_settings.modules (

    dvi = Storage(
            name_nice = T("Disaster Victim Identification"),
            description = T("Disaster Victim Identification"),

            restricted = True, # Apply controller ACLs

            module_type = 10,
            resources = Storage(
                dvi_recreq = {"importer" : True},

If restricted is False or not defined, then simple authorization is used for this controller.

The Controller ACL can be defined for all functions in a controller, and additionally for particular functions inside a controller, where the function-specific ACLs override the general controller ACL. That means, you can define a general ACL for the pr controller, and a different one for the pr/person function.

The Controller ACLs are applied to all resources when accessed through this controller/function. If the Controller ACL does not give any permission for the current user (ACL value==auth.permissions.NONE==0x00), then the request is rejected as "Unauthorized". Controllers do not have to implement this check, since this is done at a central place (in

Once the user has passed that controller permission check (must have at least read permission), and tries to access to a particular table, then the controller checks for table-specific ACLs. If there are specific ACLs defined for the table, then the most restrictive of controller and table ACLs apply (i.e. you cannot allow on the table level what you forbid at the controller level, and vice versa). If there are no specific ACLs defined for this table, then the controller ACLs apply.

Implementation of Access Control



Data Access Tracking (Audit)


Note: See TracWiki for help on using the wiki.