wiki:BluePrintAuthenticationAccess

Version 21 (modified by Fran Boon, 13 years ago) ( diff )

Separate Requirements from Implementation

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

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

Requirements

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

The specification we should be working to implement is in the Wiki:

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

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() (functional check) & t2.have_access() (record-level security)
  • we should probably support this by adding hooks into the RESTlike controller

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

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

BluePrints

Note: See TracWiki for help on using the wiki.