This page hosts the detailed specification for the ​Blueprint for Authentication & Access.

Authentication is the process that verifies the identity of a user.
Authorization provides controlled access to protected resources.

Requirements

We want to be able to provide a simple way of setting the overall security policy - allowing for flexible deployment options.

• Anonymous access is granted for all Read operations, with Create/Update/Delete requiring a user to be Authenticated
  • Self-Registration possible
  • Self-Registration not possible
• Anonymous access isn't granted for anything - all access requires a user to be Authenticated
• Modules able to be restricted by Role membership
• Tables able to be restricted by Role membership
  • C/R/U/D permissions distinct
• Records able to be restricted by Role membership
  • C/R/U/D permissions distinct

The specification we should be working to implement is in the Wiki:

• Proposed Trunk: ​http://wiki.sahana.lk/doku.php?id=dev:new_acl
• Current Stable: ​http://wiki.sahana.lk/doku.php?id=dev:security
• Old: ​http://wiki.sahana.lk/doku.php?id=dev:authorization

(NB The Vol module currently uses a separate method)

We also want to look at linking the AAA t2_person table with the Person Registry's person table

Sahana2 supports OpenID (as does Launchpad ;) ), so that would be good to support & looks easy:

• ​http://openidenabled.com/python-openid/

Implementation

S3 builds on the default T2 AAA system:

• DeveloperGuidelinesAuthenticationAccess

Anonymous access is currently granted for all Read operations, with Create/Update/Delete requiring a user to be Authenticated: t2.logged_in

• T2 can extend this by protecting resources with t2.have_membership() (functional check) & t2.have_access() (record-level security)
• we should probably support this by adding hooks into the RESTlike controller

The system supports Self-Registration, which won't be appropriate for all deployment scenarios.
To disable it requires:

• Removing the link from the menu in layout.html
• Disabling the function in controllers/default.py

If self-registration is disabled then users maintenance can be done via appadmin until we develop our own UI.
This will also be the case for adding extra roles anyway.

DRAFT:

We use t2_group table for Contact Lists information

We use s3_role table for Security access

• roles initialised in _db.py
• module writers need to add any required roles there

Membership of roles is controlled via the Many-to-Many table: s3_roleholder

T3 defines a simple t2.is_admin defined in db.py:

is_admin=(t2.logged_in and (not settings.administrator_emails or t2.person_email in settings.administrator_emails))
t2.is_admin=is_admin

• Function components protected with: if not is_admin: t2.redirect('index',flash=T('Not Authorised'))
• appadmin protected in the same way :)

Links

• Working with Realms, Users, Groups, and Roles: ​http://java.sun.com/javaee/5/docs/tutorial/doc/bnbxj.html
• Zope uses: has_permission(permission_name, view_or_controller) and/or user.has_role(custom_role) methods

---

BluePrints