wiki:BluePrintAuthenticationAccess

Version 39 (modified by Fran Boon, 16 years ago) ( diff )

Default Roles

Blueprint for Authentication, Authorization & Accounting

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

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 via a single setting in the s3_setting table.

The email address is currently not verified.

  • this should be fixed. T2 supports this: if verification

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

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:

(NB The Vol module currently uses a separate method)

We also want to look at whether we should link the AAA t2_person table with the Person Registry's person table

here are the current roles currently pre-defined during intiialisation in _db.py: 

table='t2_group'
# Populate table with Default options
if not len(db().select(db['%s' % table].ALL)):
	# Default
    #db['%s' % table].insert(
    #    name="Anonymous User",
	#)
	db['%s' % table].insert(
        name="Administrator",
        description="System Administrator - can access & make changes to any data",
	)
    # t2.logged_in is an alternate way of checking for this role
	db['%s' % table].insert(
        name="Registered User",
        description="A registered user in the system (e.g Volunteers, Family)"
	)
	db['%s' % table].insert(
        name="Super User",
        description="Global Head of Operations - can access & make changes to any data"
	)
	db['%s' % table].insert(
        name="Regional Admin",
        description="Can make changes to any data within a given Region"
	)
	db['%s' % table].insert(
        name="Country Admin",
        description="Can make changes to any data within a given Country"
	)
	db['%s' % table].insert(
        name="District Admin",
        description="Can make changes to any data within a given District"
	)
	db['%s' % table].insert(
        name="Organisation Admin",
        description="Can make changes to any data within a given Organisation"
	)
	db['%s' % table].insert(
        name="Office Admin",
        description="Can make changes to any data within a given Office"
	)
	db['%s' % table].insert(
        name="Camp Admin",
        description="Can make changes to any data within a given Camp"
	)

Implementation

S3 builds on the default T2 AAA system:

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

We use t2_group table for Roles & t2_membership to show which roles a user has.

  • roles initialised in _db.py
  • 1st user to register gets Administrator role
  • module writers need to add any required roles there

We expose this as s3.roles so that it is accessible to Controllers & Views.
e.g.

  • appadmin.py
  • layout.html

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

Accounting

STATUS: Complete apart from needing to get new_values back from the form after processing.
The solution hooks the RESTlike controller so anything which bypasses that is not logged (unless using the T2 fields: created_by, updated_by).
To do more would require patching the DAL.

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.
Per-Module settings are defined in module_settings table.
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

For now this is configured via appadmin, although we should later make a nicer UI which has a single checkbox for 'Enable Auditing'. This then opens up a two checkboxes:

  • Global
  • Module-specific

If each is ticked, this sets the audit_write & opens up an extra checkbox for 'Enable Auditing of Reads' (sets audit_read).

BluePrints

Note: See TracWiki for help on using the wiki.