[Zope3-checkins] CVS: Zope3/lib/python/Zope/Security - README.txt:1.2
Barry Warsaw
barry@wooz.org
Tue, 10 Dec 2002 11:16:31 -0500
Update of /cvs-repository/Zope3/lib/python/Zope/Security
In directory cvs.zope.org:/tmp/cvs-serv1780
Modified Files:
README.txt
Log Message:
Typos and spell checks
=== Zope3/lib/python/Zope/Security/README.txt 1.1 => 1.2 ===
--- Zope3/lib/python/Zope/Security/README.txt:1.1 Fri Dec 6 07:11:35 2002
+++ Zope3/lib/python/Zope/Security/README.txt Tue Dec 10 11:16:30 2002
@@ -3,58 +3,58 @@
Introduction
The Security framework provides a generic mechanism to implement
- security policies on python objects. This introduction provides
- a tutorial of the framework explaining concepts, design, and
- going through sample usage from the perspective of a python
- programmer using the framework outside of Zope.
-
+ security policies on Python objects. This introduction provides a
+ tutorial of the framework explaining concepts, design, and going
+ through sample usage from the perspective of a Python programmer
+ using the framework outside of Zope.
+
Definitions
Principal
- A generalization of a concept of a user. a principal may be
+ A generalization of a concept of a user. A principal may be
associated with different roles and permissions.
Permission
-
- A kind of access. ie permission to READ vs. permission to WRITE
- fundamentally the whole security framework is organized around
- checking permissions on objects.
+
+ A kind of access, i.e. permission to READ vs. permission to
+ WRITE. Fundamentally the whole security framework is organized
+ around checking permissions on objects.
Roles
- represents a reposibility of a user in the context of an object.
- Roles are associated with the permissions nesc. to fufill the
- user's responsiblity.
+ Represents a responsibility of a user in the context of an
+ object. Roles are associated with the permissions necessary to
+ fulfill the user's responsibility.
Purpose
The security framework's primary purpose is to guard and check
- access to python objects. It does this by providing mechanisms
- for explicit and implicit security checks on attribute access
- for objects. Attribute names are mapped onto permission names when
- checking accesss and the implementation of the security check is
- defined by the security policy, which recieves the object, the
- permission name, and a context.
-
- Security contexts are containers of transient information such
- as the current principal and the context stack.
-
- To explain the concept and usage of the context stack a little
- background into the design influences of the default zope policy
- is needed, namely the java language security model. Within the
- base language, code is associated with identifiers. ie this code
- came from joe schmoe, and another code archive comes signed from
- verisign. when executing restricted code, its important access
+ access to Python objects. It does this by providing mechanisms
+ for explicit and implicit security checks on attribute access for
+ objects. Attribute names are mapped onto permission names when
+ checking access and the implementation of the security check is
+ defined by the security policy, which receives the object, the
+ permission name, and a context.
+
+ Security contexts are containers of transient information such as
+ the current principal and the context stack.
+
+ To explain the concept and usage of the context stack, a little
+ background into the design influences of the default Zope policy
+ is needed, namely the Java language security model. Within the
+ base language, code is associated with identifiers. I.e. this code
+ came from "Joe Schmoe", and another code archive comes signed from
+ Verisign. When executing restricted code, it's important access
is checked not only for the code currently executing but for the
- entire call/context stack (unless explictly short-circuited). ie
- if joe schmoe's code does haven't access to the filesystem, but if
- the verisign code does, joe's code could circumvent the security
- policy by accessing the filesystem via the verisign code.
-
- Its important to keep in mind that the policy provided is just
- a default, and it can be substituted with one which doesn't
- care about principals or context stacks at all.
+ entire call/context stack (unless explicitly short-circuited).
+ I.e. if Joe Schmoe's code does haven't access to the filesystem,
+ but if the Verisign code does, Joe's code could circumvent the
+ security policy by accessing the filesystem via the Verisign code.
+
+ Its important to keep in mind that the policy provided is just a
+ default, and it can be substituted with one which doesn't care
+ about principals or context stacks at all.
Framework Components
@@ -66,88 +66,87 @@
Checkers
- a checker is associated with an object kind, and provides
- the hooks that map attribute checks onto permissions
- deferring to the security manager (which in turn defers to the
- policy) to perform the check.
+ A checker is associated with an object kind, and provides the
+ hooks that map attribute checks onto permissions deferring to
+ the security manager (which in turn defers to the policy) to
+ perform the check.
- additionally checkers, provide for creating proxies of objects
+ Additionally, checkers provide for creating proxies of objects
associated with the checker.
-
- there are several implementation variants of checkers
- from checkers that grant access based on attribute names,
-
+
+ There are several implementation variants of checkers, such as
+ checkers that grant access based on attribute names.
+
Proxies
-
- Wrappers around python objects that implictly guard
- access to their wrapped contents by delegating to their
- associated checker. Proxies are also viral in nature,
- in that values returned by proxies are also proxied.
-
+
+ Wrappers around Python objects that implicitly guard access to
+ their wrapped contents by delegating to their associated
+ checker. Proxies are also viral in nature, in that values
+ returned by proxies are also proxied.
+
High Level Components
Security Management
- Provides accessors for setting up security manager
- and global security policy
+ Provides accessors for setting up security manager and global
+ security policy.
Security Context
- stores transient information on the current principal and
- the context stack.
+ Stores transient information on the current principal and the
+ context stack.
Security Manager
- manages security context (execution stack) and delegates
+ Manages security context (execution stack) and delegates
permission checks to security policy.
Security Policy
- provides a single method that accepts the object, the
- permission, and the context of the access being checked
- and is used to implement the application logic for
- the security framework.
+ Provides a single method that accepts the object, the
+ permission, and the context of the access being checked and is
+ used to implement the application logic for the security
+ framework.
Narrative (agent sandbox)
As an example we take a look at constructing a multi-agent
- distributed system, and then adding a security layer using
- the zope security model onto it.
+ distributed system, and then adding a security layer using the
+ Zope security model onto it.
Scenario
- Our agent simulation consists of autonomous agents that
- live in various agent homes/sandboxes and perform actions
- that access services available at their current
- home. Agents carry around authentication tokens
- which signify their level of access within any given home.
- Additionally agents attempt to migrate from home to home
- randomly.
-
- the agent simulation was constructed separately from any
- security aspects. now we want to define and integrate a
- security model into the simulation. the full code for
- the simulation and the security model is available separately
- we present only relevant code snippets here for illustration
- as we go through the implementation process.
-
- for the agent simulation we want to add a security model such
- that we group agents into two authentication groups, norse
- legends, including the principals thor, odin, and loki, and
- greek men, including prometheus, archimedes, and thucydides.
-
- we associate permissions with access to services, and homes.
- and differentiate the homes such that certain authentication
- groups only have access to services or the the home itself
- based on the local settings of the home in which they reside.
+ Our agent simulation consists of autonomous agents that live in
+ various agent homes/sandboxes and perform actions that access
+ services available at their current home. Agents carry around
+ authentication tokens which signify their level of access within
+ any given home. Additionally agents attempt to migrate from
+ home to home randomly.
+
+ The agent simulation was constructed separately from any
+ security aspects. now we want to define and integrate a
+ security model into the simulation. The full code for the
+ simulation and the security model is available separately; we
+ present only relevant code snippets here for illustration as we
+ go through the implementation process.
+
+ For the agent simulation we want to add a security model such
+ that we group agents into two authentication groups, "norse
+ legends", including the principals thor, odin, and loki, and
+ "greek men", including prometheus, archimedes, and thucydides.
+
+ We associate permissions with access to services and homes. We
+ differentiate the homes such that certain authentication groups
+ only have access to services or the home itself based on the
+ local settings of the home in which they reside.
- we define the homes/sandboxes
+ We define the homes/sandboxes
- origin - all agents start here, and have access to all
services here.
- - valhalla - only agents in the authentication group
- 'norse legend' can reside here.
+ - valhalla - only agents in the authentication group 'norse
+ legend' can reside here.
- jail - all agents can come here, but only 'norse legend's
can leave or access services.
@@ -155,9 +154,9 @@
Process
- loosely we define a process for implementing this security model
-
- - mapping permissions on to actions
+ Loosely we define a process for implementing this security model
+
+ - mapping permissions onto actions
- mapping authentication tokens onto permissions
@@ -166,11 +165,11 @@
- binding checkers to our simulation classes
- - inserting the hooks into the original simulation code to add
+ - inserting the hooks into the original simulation code to add
proxy wrappers to automatically check security.
-
- - inserting hooks into the original simulation to register
- the agents as the active principal within a security manager's
+
+ - inserting hooks into the original simulation to register the
+ agents as the active principal within a security manager's
context....
Defining Permission Model
@@ -184,19 +183,18 @@
AccessAgents = 'Access Agents'
AccessTimeService = 'Access Time Services'
AccessAgentService = 'Access Agent Service'
- AccessHomeService = 'Access Home Service'
+ AccessHomeService = 'Access Home Service'
- and create a dictionary database mapping homes
- to authentication groups which are linked
- to associated permissions.
+ and create a dictionary database mapping homes to authentication
+ groups which are linked to associated permissions.
Defining and Binding Checkers
- Checkers are the foundational unit for the security framework
- they define what attributes can be accessed or set on a given
- instance. they can be used implicitly via Proxy objects, to
- guard all attribute access automatically or explictly to check
- a given access for an operation.
+ Checkers are the foundational unit for the security framework.
+ They define what attributes can be accessed or set on a given
+ instance. They can be used implicitly via Proxy objects, to
+ guard all attribute access automatically or explicitly to check a
+ given access for an operation.
Checker construction expects two functions or dictionaries, one
is used to map attribute names to permissions for attribute
@@ -204,12 +202,13 @@
We use the following checker factory function::
- def PermissionMapChecker(permissions_map={}, setattr_permission_func=NoSetAttr):
+ def PermissionMapChecker(permissions_map={},
+ setattr_permission_func=NoSetAttr):
res = {}
for k,v in permissions_map.items():
for iv in v:
res[iv]=k
- return Checker.Checker(res.get, setattr_permission_func)
+ return Checker.Checker(res.get, setattr_permission_func)
time_service_checker = PermissionMapChecker(
# permission : [methods]
@@ -219,31 +218,29 @@
with the NoSetAttr function defined as a lambda which always
return the permission NotAllowed
- To bind the checkers to the simulation classes we register
- our checkers with the security model's global checker registry::
-
+ To bind the checkers to the simulation classes we register our
+ checkers with the security model's global checker registry::
+
import sandbox_simulation
from Zope.Security.Checker import defineChecker
defineChecker(sandbox_simulation.TimeService, time_service_checker)
Defining a Security Policy
-
- we implement our security policy such that it checks the
- current agent's authentication token against the given
- permission against the home of the object being accessed.
- in code::
+ We implement our security policy such that it checks the current
+ agent's authentication token against the given permission in the
+ home of the object being accessed::
class SimulationSecurityPolicy:
__implements__ = ISecurityPolicy
-
+
def checkPermission(self, permission, object, context):
token = context.user.getAuthenticationToken()
home = object.getHome()
db = getattr(SimulationSecurityDatabase, home.getId(), None)
-
+
if db is None:
return False
@@ -254,62 +251,63 @@
allowed = db.get(token, ())
if permission in allowed:
return True
-
+
return False
- there is some additional code present to allow for shortcuts
- in defining the permission database when defining permissions
- for all auth groups and all permissions.
+ There is some additional code present to allow for shortcuts in
+ defining the permission database when defining permissions for
+ all auth groups and all permissions.
Integration
- At this point we have implemented our security model, and
- we need to integrate it with our simulation model. we do so
- in three separate steps.
-
- first we make it such that agents only access homes that are
- wrapped in a security proxy. by doing this all access to homes
- and services (proxies have proxied return values for their
+ At this point we have implemented our security model, and we
+ need to integrate it with our simulation model. We do so in
+ three separate steps.
+
+ First we make it such that agents only access homes that are
+ wrapped in a security proxy. By doing this all access to homes
+ and services (proxies have proxied return values for their
methods) is implicitly guarded by our security policy.
- the second step is that we want to associate the active agent
- with the security context so the security policy will know
- which agent's authentication token to validate against.
+ The second step is that we want to associate the active agent
+ with the security context so the security policy will know which
+ agent's authentication token to validate against.
- the third step is to set our security policy as the default
- policy for the zope security framework. it is possible to
+ The third step is to set our security policy as the default
+ policy for the Zope security framework. It is possible to
create custom security policies at a finer grained than global,
but such is left as an exercise for the reader.
Security Manager Access
- The *default* implementation of the security management interfaces
- defines security managers on a per thread basis with a function
- for an accessor, this model is not appropriate for all systems,
- as it restricts one to a single active user per thread at any
- given moment, reimplementing the manager access methods though
- is easily doable and is noted here for completeness.
+ The *default* implementation of the security management
+ interfaces defines security managers on a per thread basis with
+ a function for an accessor. This model is not appropriate for
+ all systems, as it restricts one to a single active user per
+ thread at any given moment. Reimplementing the manager access
+ methods though is easily doable and is noted here for
+ completeness.
Perspectives
- Its important to keep in mind that there is alot more that
- is possible using the security framework thans what been
- presented here. all of the interactions are interfaced based,
- such that if you need to reimplement the semantics to suite
- your application a new implementation of the interface will be
- sufficient. Additional possiblities range from restricted
- interpreters and dynamic loading of untrusted code to non zope
- web application security systems.. insert imagination here ;-).
+ It's important to keep in mind that there is a lot more that is
+ possible using the security framework than what's been presented
+ here. All of the interactions are interface based, such that if
+ you need to re-implement the semantics to suite your application
+ a new implementation of the interface will be sufficient.
+ Additional possibilities range from restricted interpreters and
+ dynamic loading of untrusted code to non Zope web application
+ security systems. Insert imagination here ;-).
Zope Perspective
A Zope3 programmer will never commonly need to interact with the
- low level security framework. Zope3 defines a second security
- package overtop the low level framework that implements concepts
- of roles and authentication sources and checkers are handled via
- zcml registration. Still those developing Zope3, will hopefully
- find this useful as an introduction into the underpinnings of
- the security framework.
+ low level security framework. Zope3 defines a second security
+ package over top the low level framework that implements concepts
+ of roles, and authentication sources and checkers are handled
+ via zcml registration. Still those developing Zope3 will
+ hopefully find this useful as an introduction into the
+ underpinnings of the security framework.
Code
@@ -319,10 +317,9 @@
sandbox_security.py - the security implementation and binding to
the agent framework.
-
+
Author
Kapil Thangavelu <hazmat at objectrealms.net>
-
+
Guido Wesdorp <guido at infrae.com>
-