Mercurial Repository: p/roundup/code: doc/security.txt comparison

comparison doc/security.txt @ 910:299f4890427d

documentation reorg post-new-security

author	Richard Jones <richard@users.sourceforge.net>
date	Mon, 29 Jul 2002 23:30:14 +0000
parents	38a74d1351c5
children	43ab730ee194

comparison

equal deleted inserted replaced

-:ef9c759c243e
+:299f4890427d
 ===================
 Security Mechanisms
 ===================
-:Version: $Revision: 1.14 $
+:Version: $Revision: 1.15 $
 Current situation
 =================
 Current logical controls:
 - much more work to implement
 - most user interfaces have multiple uses which can't be covered by a
 single permission
 Logical control
 ---------------
 At each point that requires an action to be performed, the security mechanisms
 are asked if the current user has permission. Since code must call the
 - large number of possible permissions that may be defined, possibly
 mirroring actual user interface controls.
 - access to the hyperdb must be strictly controlled through program code
 that implements the logical controls.
-Applying controls to users
-==========================
-Individual assignment of Permission to User is unwieldy. The concept of a
-Role, which encompasses several Permissions and may be assigned to many Users,
-is quite well developed in many projects. Roundup will take this path, and
-allow the multiple assignment of Roles to Users, and multiple Permissions to
-Roles. These definitions are not persistent - they're defined when the
-application initialises.
-There will be two levels of Permission. The Class level permissions define
-logical permissions associated with all nodes of a particular class (or all
-classes). The Node level permissions define logical permissions associated
-with specific nodes by way of their user-linked properties.
-The security module defines::
-class Permission:
-''' Defines a Permission with the attributes
-- name
-- description
-- klass (optional)
-The klass may be unset, indicating that this permission is not
-locked to a particular hyperdb class. There may be multiple
-Permissions for the same name for different classes.
-'''
-class Role:
-''' Defines a Role with the attributes
-- name
-- description
-- permissions
-'''
-class Security:
-def __init__(self, db):
-''' Initialise the permission and role stores, and add in the
-base roles (for admin user).
-'''
-def getPermission(self, permission, classname=None):
-''' Find the Permission matching the name and for the class, if the
-classname is specified.
-Raise ValueError if there is no exact match.
-'''
-def hasPermission(self, permission, userid, classname=None):
-''' Look through all the Roles, and hence Permissions, and see if
-"permission" is there for the specified classname.
-'''
-def hasNodePermission(self, classname, nodeid, **propspec):
-''' Check the named properties of the given node to see if the
-userid appears in them. If it does, then the user is granted
-this permission check.
-'propspec' consists of a set of properties and values that
-must be present on the given node for access to be granted.
-If a property is a Link, the value must match the property
-value. If a property is a Multilink, the value must appear
-in the Multilink list.
-'''
-def addPermission(self, **propspec):
-''' Create a new Permission with the properties defined in
-'propspec'
-'''
-def addRole(self, **propspec):
-''' Create a new Role with the properties defined in 'propspec'
-'''
-def addPermissionToRole(self, rolename, permission):
-''' Add the permission to the role's permission list.
-'rolename' is the name of the role to add permission to.
-'''
-Modules such as ``cgi_client.py`` and ``mailgw.py`` define their own
-permissions like so (this example is ``cgi_client.py``)::
-def initialiseSecurity(security):
-''' Create some Permissions and Roles on the security object
-This function is directly invoked by security.Security.__init__()
-as a part of the Security object instantiation.
-'''
-newid = security.addPermission(name="Web Registration",
-description="Anonymous users may register through the web")
-security.addToRole('Anonymous', newid)
-The instance dbinit module then has in ``open()``::
-# open the database - it must be modified to init the Security class
-# from security.py as db.security
-db = Database(instance_config, name)
-# add some extra permissions and associate them with roles
-ei = db.security.addPermission(name="Edit", klass="issue",
-description="User is allowed to edit issues")
-db.security.addPermissionToRole('User', ei)
-ai = db.security.addPermission(name="View", klass="issue",
-description="User is allowed to access issues")
-db.security.addPermissionToRole('User', ai)
-In the dbinit ``init()``::
-# create the two default users
-user.create(username="admin", password=Password(adminpw),
-address=instance_config.ADMIN_EMAIL, roles='Admin')
-user.create(username="anonymous", roles='Anonymous')
-Then in the code that matters, calls to ``hasPermission`` and
-``hasNodePermission`` are made to determine if the user has permission
-to perform some action::
-if db.security.hasPermission('issue', 'Edit', userid):
-# all ok
-if db.security.hasNodePermission('issue', nodeid, assignedto=userid):
-# all ok
-Code in the core will make use of these methods, as should code in auditors in
-custom templates. The htmltemplate will implement a new tag, ``<require>``
-which has the form::
-<require permission="name,name,name" assignedto="$userid" status="open">
-HTML to display if the user has the permission.
-<else>
-HTML to display if the user does not have the permission.
-</require>
-where:
-- the permission attribute gives a comma-separated list of permission names.
-These are checked in turn using ``hasPermission`` and requires one to
-be OK.
-- the other attributes are lookups on the node using ``hasNodePermission``. If
-the attribute value is "$userid" then the current user's userid is tested.
-Any of these tests must pass or the ``<require>`` check will fail. The section
-of html within the side of the ``<else>`` that fails is remove from processing.
-Implementation as shipped
--------------------------
-A set of Permissions are built in to the security module by default:
-- Edit (everything)
-- View (everything)
-The default interfaces define:
-- Web Registration
-- Email Registration
-These are hooked into the default Roles:
-- Admin (Edit everything, View everything)
-- User ()
-- Anonymous (Web Registration, Email Registration)
-And finally, the "admin" user gets the "Admin" Role, and the "anonymous" user
-gets the "Anonymous" assigned when the database is initialised on installation.
-The two default schemas then define:
-- Edit issue, View issue (both)
-- Edit file, View file (both)
-- Edit msg, View msg (both)
-- Edit support, View support (extended only)
-and assign those Permissions to the "User" Role. New users are assigned the
-Roles defined in the config file as:
-- NEW_WEB_USER_ROLES
-- NEW_EMAIL_USER_ROLES
-Authentication of Users
------------------------
-Users must be authenticated correctly for the above controls to work. This is
-not done in the current mail gateway at all. Use of digital signing of
-messages could alleviate this problem.
-The exact mechanism of registering the digital signature should be flexible,
-with perhaps a level of trust. Users who supply their signature through their
-first message into the tracker should be at a lower level of trust to those
-who supply their signature to an admin for submission to their user details.
-Anonymous Users
----------------
-The "anonymous" user must always exist, and defines the access permissions for
-anonymous users. The three ``ANONYMOUS_`` configuration variables are
-subsumed by this new functionality.
 Action
 ======
 - use the new logical control mechanisms (only allowing write
 access by admin users, and read-only by everyone else)
-Use cases
-=========
-public
-end users that can submit bugs, request new features, request support
-developer
-developers that can fix bugs, implement new features provide support
-manager
-approvers/managers that can approve new features and signoff bug fixes
-admin
-administrators that can add users and set user's roles
-system
-automated request handlers running various report/escalation scripts
-privacy
-issues that are only visible to some users

Mercurial > p > roundup > code

comparison doc/security.txt @ 910:299f4890427d