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

'''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.[[BR]]
'''Accounting''' refers to the tracking of user actions - an audit trail.[[BR]]

== 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 via a single setting in the s3_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

== Accounting ==
Events can be audited at the Global level or the per-Module level.

Most auditing wins, so if the Global is True, then all Modules will Log. If Global is False then Modules have control & can selectively enable it.

Global settings are defined in {{{s3_settings}}} table.[[BR]]
Per-Module settings are defined in {{{module_settings}}} table.[[BR]]
Each defines 2 levels of Auditing - Audit just Changes (C/U/D), or also Reads:
  * {{{audit_read}}}
  * {{{audit_write}}}

These are passed to the session for use in controllers/displays:
  * {{{session.s3.audit_read}}}
  * {{{session.s3.audit_write}}}

They are enforced via the [wiki:BluePrintREST RESTlike controller]

For now this is configured via appadmin, although we should later make a nicer UI which has a single checkbox for 'Enable Auditing' (sets {{{audit_write}}}), which then opens up a 2nd checkbox for 'Enable Auditing of Reads' (sets {{{audit_read}}}).

----
BluePrints