wiki:BluePrintAuthorization

Version 58 (modified by Fran Boon, 14 years ago) ( diff )

--

BluePrint for Authorization

Restrictions

Module restriction

  • s3.modules in 01_modules.py
  • Add Controller check as well as menu check.
    • appadmin.py & dvi.py have these already
  • Configure permissions in 000_config.py instead of 01_modules.py
    • Change deployment_settings.modules from a list of strings to a Storage()
      # Need to define Roles in dict for visibility by modules before inserted into DB
      deployment_settings.auth.roles = {
          1 : "Administrator",
          2 : "Authenticated",
          ....
          6 : "AdvancedJS",
      }
      
      deployment_settings_modules = Storage(
          gis = Storage(
              name_nice = "Mapping",
              description = "Situation Awareness & Geospatial Analysis",
              readable = None,    # All Users (inc Anonymous) can see this module in the default menu & access the controller
              writable = None,    # All Authenticated users can edit resources which aren't specially protected
              module_type = 2,    # Used to locate the module in the default menu
              resources = Storage(
                  apikey = {
                          read : "|1|",     # This resource is only visible to Administrators
                      },
                  layer_js = {
                          create : "|%d|" % deployment_settings.auth.roles["AdvancedJS"],    # This resource requires the 'AdvancedJS' role to create (or admin)
                          delete : "|%d|" % deployment_settings.auth.roles["AdvancedJS"],    # This resource requires the 'AdvancedJS' role to delete (or admin)
                          update : "|%d|" % deployment_settings.auth.roles["AdvancedJS"],    # This resource requires the 'AdvancedJS' role to update (or admin)
                      }
              ),
          ),
          ...
      )
      

Function restriction

  • Decorator function : @auth.requires_membership("Administrator")
    • doesn't support OR, doesn't support NOT
  • We need to write a function which handles OR & NOT: shn_role_check(1, 2, not=(3))
  • Developer can put in additional manual restrictions or alternate routes, as-required

Resource restriction

  • Bad: REST controller can be blocked via a Decorator
    • we'd need to patch other functions, such as sync, which would be hard to maintain
  • Bad: Full security policy (native web2py) can be invoked, but this is painful (based on protected by default & granted manually) & untested within S3 recently
  • Need a new method: open by default & restricted manually
    • Option1: Use an auth_permission table similar to Web2Py 'full' but just for tables & with group_id as multiple=True
    • Option2: Set within 000_config.py, along with module permissions (see above example)
      • Means less DAL calls
    • Option3: Have an onvalidation which auto-populates the reader_id/writer_id fields in records
      • Means that no additional auth check at table-level needed
      • Means that the security model isn't held all in one place, so not as easy to maintain?
      • If done at validation time then it means that no extra DAL calls are done when creating resources (just extra field(s) within the 1 DAL call)
    • Once new solution in-place:
      • remove security_policy from s3_setting table & session (00_utils.py)
      • modify shn_action_buttons() in 00_utils.py

Record restriction

  • Add 2 reusable multiple=True fields to each table which needs this: reader_id & writer_id combined as permissions_id for easy reuse within table definitions
    • Full backward compatibility since they default to None
  • For List views modify shn_accessible_query() (called from shn_list() & shn_search())
    • combine with the deleted==True check
      • makes it easier to then replace that check with an 'inactive' field which is a date instead of a boolean, so that records can be set to expire (as well as giving us easy access to know when a record was deleted)
    • Preferred Option: Do the check alongside deleted as part of a big JOIN
      def shn_accessible_query(table):
          """
          Return a filter of those records which are readable by the currently logged-in user
          - deleted records are filtered
          - records to which they don't have permissions are filtered
          """
      
          if "deleted" in table.fields:
              deleted = (table.deleted == None)
          else:
              deleted = 1
      
          try:
              user_id = auth.user.id
              _memberships = db.auth_membership
              memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
          except:
              memberships = None
          
          roles = []
          for membership in memberships:
              roles.append(membership.group_id)
      
          if 1 in roles:
              # Admins see all data
              query = deleted
          else:
             # Fields with no restriction
             accessible = (table.reader_id == None)
             for role in roles:
                 #accessible = accessible & (table.reader_id == str(role)) & (table.reader_id.like('%d|%' % role)) & (table.reader_id.like('%|%d|%' % role)) & (table.reader_id.like('%|%d' % role))
                 accessible = accessible & (table.reader_id.like('%|%d|%' % role))
             query = deleted & accessible
          return query
      
      def user_function():
          ...
          table = db[tablename]
          available = shn_accessible_query(table)
          query = available & query
          ...
      
      • Advantages:
        • Combines the deleted into single API call
        • Single JOIN for optimal DB performance (Assumption needs testing)
    • Alternate Option: Do the check in Python after the initial query has returned
      • Advantage: Might have better performance than complex DB string?
      • Disadvantage: More records pulled from DB than necessary
  • For single records modify shn_has_permission() (called from shn_create(), shn_delete(), shn_read() & shn_update(), but also available for other functions)
    def shn_has_permission(name, tablename, record_id = 0):
        """
            S3 framework function to define whether a user can access a record in manner "name"
        """
    
        try:
            user_id = auth.user.id
            _memberships = db.auth_membership
            memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
        except:
            memberships = None
        
        roles = []
        for membership in memberships:
            roles.append(membership.group_id)
    
        table = db[tablename]
        # Check if table is restricted (Options 1 & 2)
        if 1 in roles:
            # Admins see all tables
            authorised = True
        else:   
            # Option 1
            #restriction = db(db.auth_permission.table_name == tablename).select(db.auth_permission.group_id, limitby=(0, 1), cache=(cache.ram, 60)).first().group_id
            #if restriction:
            #   authorised = False
            #   restrictions = re.split("\|", restriction)[1:-1]
                # Assume we generally have fewer restrictions than roles
            #   for restriction in restrictions:
            #        if restriction == "0" or int(restriction) in roles:
                         # restriction 0 is anonymous
            #            authorised = True
            #else:
            #    authorised = True 
    
            # Option 2
            module, resource = tablename.split("_", 1)
            try:
                restriction = deployment_settings_modules["module"].resources["resource"]["name"]
            except:
                restriction = None
            
            if restriction:
                authorised = False
                restrictions = re.split("\|", restriction)[1:-1]
                # Assume we generally have fewer restrictions than roles
                for restriction in restrictions:
                    if restriction == "0" or int(restriction) in roles:
                        # restriction 0 is anonymous
                        authorised = True
                    
            else:
                # No restriction
                authorised = True
    
        # Options 3:
        #if record_id:
        # Options 1 & 2:
        if record_id and authorised:
    
            record = None
    
            if "deleted" in table.fields:
                # Check if record is deleted
                record = db(table.id == record_id).select(table.deleted, table.reader_id, table.writer_id, limitby=(0, 1)).first()
                if record.deleted:
                    authorised = False
                    return authorised
    
            elif 1 in roles:
                # Admin is always authorised to view undeleted data (deleted data accessible through alternate UI)
                authorised = True
                return authorised
    
            # Check the record's auth fields
            if not record:
                record = db(table.id == record_id).select(table.reader_id, table.writer_id, limitby=(0, 1)).first()
            if name == "read":
                if not table.reader_id:
                    authorised = True
                else:
                    authorised = False
                    restrictions = re.split("\|", table.reader_id)[1:-1]
                    # Assume we generally have fewer restrictions than roles
                    for restriction in restrictions:
                        if restriction in roles:
                            authorised = True
                    
            elif name in ["delete", "update"]:
                if not table.writer_id:
                    authorised = True
                else:
                    authorised = False
                    restrictions = re.split("\|", table.writer_id)[1:-1]
                    # Assume we generally have fewer restrictions than roles
                    for restriction in restrictions:
                        if restriction == "0" or int(restriction) in roles:
                            # restriction 0 is anonymous
                            authorised = True
    
            else:
                # Something went wrong
                session.error = str(T("Invalid mode sent to")) + " shn_has_permission(): " + name
                redirect(URL(r=request, f="index"))
    
    return authorised
    
  • UI to manage the fields.
    • We expect relatively few groups per instance, so can use the checkboxes widget?
      • can filter out some groups?
    • Have a single checkbox for 'Restrict access' which then opens out the 2 fields.

Field restriction

  • In model (for access by all controllers, such as sync):
    try:
        user_id = auth.user.id
        _memberships = db.auth_membership
        memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
    except:
        memberships = None
    
    roles = []
    for membership in memberships:
        roles.append(membership.group_id)
    
    if 1 not in roles and deployment_settings.auth.roles["MyRole"] not in roles:
        table.field.readable = False
    
    • NB If doing this then the roles checks inside shn_has_permission() & shn_accessible_fields() should be modified to read this global value instead of more DAL queries (even cached)!

Location restriction

e.g. Country or Region

  • Add a special role 'Geographic' which can be added to writer_id (& maybe reader_id although less use case for this)
    • Patch shn_has_permission() (& maybe shn_accessible_query()) to spot this special case &, if no other roles match, then do a lookup in another table (or deployment_settings dict)
  • NB If doing this through a table, then need to ensure that this table is protected appropriately

Organisation restriction

  • This could be all members of the Organisation or just the 'Focal Point'
  • Add a special role 'Organisation' which can be added to writer_id (& maybe reader_id although less use case for this)
    • Patch shn_has_permission() (& maybe shn_accessible_query()) to spot this special case &, if no other roles match, then do a lookup in another table (or deployment_settings dict)
  • NB If doing this through a table (such as a person's organisation), then need to ensure that this table is protected appropriately

Author restriction

Only allow a user to update records which they created.

  • Add a special role 'Creator' which can be added to writer_id (& maybe reader_id although less use case for this)
    • Patch shn_has_permission() (& maybe shn_accessible_query()) to spot this special case &, if no other roles match, then do a check between auth.user.id & table.created_by

Anonymous authoring

Some tables should be writable by unauthenticated users

  • Need to differentiate the 2 (can deposit new but not edit existing)
  • Function shn_has_permission() above handles this by the admin setting the relevant permission to |0|
  • Might want to be have new records by unauthenticated users not be visible in lists until an admin has approved them
    • Add a new field 'approved', which default to 'False' for unauthenticated users
    • Filter for this: query = query & (table.approved == True)
      • Q: Do we keep this in individual controllers
        • manual & need to check additional functions like Sync
      • Q: Do we do check globally within shn_accessible_query() & shn_has_permission
        • means extra logic every CRUD check when most resources don't need this

Visibility of Options

Ideally options which a user doesn't have permission for should be hidden from them.

  • Modules are hidden from Modules menu & front page
  • Action buttons in tables only show 'Details' for unauthenticated users, but 'Update'/'Delete' for authenticated ones
    • ideally would distinguish per record if some records restricted (We already pull the data for the rows, so need to ensure SQL query includes relevant fields & that we act upon them)
  • Controller menus should be adjusted (currently done manually => harder maintenance)
  • Views should be adjusted (currently done manually => harder maintenance)

Specific Examples

  • A Person's Contacts shouldn't be visible by default.
    • Authenticated is OK
      • Simply add the Authenticated group (2) to the table (or records in the table if using Option 3)
      • This requires all authenticated users to be added to the 'Authenticated' group
  • A Person's Subscriptions shouldn't be visible by default.
    • Admin or themselves is OK
      • Option A: restore the web2py default of adding 1 group per user!
        • In models/00_settings.py: auth.settings.create_user_groups = True
        • Check using auth.user_group(auth.user.id)
        • Filter these out of our views?
      • Option B: use the link from subscription to person & do manual check somewhere
        • tbc
    • We may want to allow people to be subscribed to things by others.
      • This would need a 'Subscriber Admin' role
        • We could give this role to all registered users by default if we Hook into the registration onaccept
          • Currently this requires modifying shn_register() in modules/sahana.py
          • Replace with a registration_onvalidation and a registration_onaccept hook, which operate with secured copies of the registration data (e.g. no password contained).
  • Messaging: If access to a record is restricted then access to Messages relating to that record should also be restricted
    • unless routed somewhere visible as well!
    • block subscription
    • onvalidation on message routing (i.e. tagging) to check if the only tags are on restricted resources...if they are then restrict the message too.
      • onvalidation not onaccept so that only 1 DAL update() is done
  • FRP: a request that has been submitted by an IP user can be completely changed as well as cancelled/deleted by IP users belonging to the same organisation, but only until a WFP user has confirmed the request - after that the IP users can only change certain fields in the record, and not delete the record anymore.
    • Field in requests table 'confirmed' which is writable=False unless role==WFP
    • onvalidation for requests does a check whether confirmed is set &, if it is, only allows the relevant fields to be changed & denies deletion
  • FRP: if a user has a role which would normally be granted permission to a resource has another role, then deny them access instead.
    • shn_role_check covers this: BluePrintAuthorization
    • Option: Introduce full-blown model of Persons -> Groups (pr_group) -> Roles (auth_group) -> Permissions
      • Downside: Extra layer of confusion for both Admins & Developers
      • Upside: Very flexible for Admins to manage which users (in bulk & future members) get what access to resources (subject to sufficient roles being made available by the developer)

BluePrintAuthenticationAccess

BluePrints

Note: See TracWiki for help on using the wiki.