This page hosts the detailed specification for the [https://blueprints.launchpad.net/sahana3/+spec/authentication-authorization Blueprint for the Authentication & Access].

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

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


S3 builds on the default T2 AAA system:
 * http://trac.sahana3.org/wiki/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 [wiki:BluePrintREST RESTlike controller]

The system supports Self-Registration, which won't be appropriate for all deployment scenarios.[[BR]]
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.[[BR]]
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}}}


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

S2 supports OpenID (as does Launchpad ;) ), so that would be good to support & looks easy:
 * http://openidenabled.com/python-openid/

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 :)

 * 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