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

Authentication is the act of establishing or confirming someone's identity.[[BR]]
Authorization is the concept of allowing access to resources only to those permitted to use them.

== Authentication ==
!SahanaPy currently authenticates on email address/password.[[BR]]
- this is the T2 method.

The default configuration is that Self-Registration is enabled.[[BR]]
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.[[BR]]
- 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 [wiki:BluePrintREST RESTlike controller]

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

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