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

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.

Authentication

SahanaPy currently authenticates on email address/password.

• this is the T2 method.

The default configuration is that Self-Registration is enabled.
This can be easily disabled:

• Remove the link from the menu in layout.html
• Disable the function in controllers/default.py

This manual process should be changed to a single setting in the default_setting table.

The email address is currently not verified.

• this should be fixed.

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

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

Authorization

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
• 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

Sahana2 specifications:

• 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

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() (table level security which can be separated for C/R/U/D) & t2.have_access() (record-level security)
• we should probably support these by adding hooks into the RESTlike controller

User maintenance can be done via appadmin until we develop our own UI.

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

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

---

BluePrints