Overview and 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.



A generalization of a concept of a user. Further specializations include groups of users and principals that know what groups they belong to. All of these principals may interact with the system.


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. Permissions are represented (and checked) as strings, with the exception of a constant that has the special meaning of “public”, i.e., no checking needs to be done.

There are permission objects that can be registered as zope.component utilities for validation, introspection, and producing lists of available permissions to help users assign them to objects.


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 access and the implementation of the security check is defined by the security policy, which receives the object, the permission name, and an interaction.

Interactions are objects that represent the use of the system by one or more principals. An interaction contains a list of participations, which represents the way a single principal participates in the interaction. An HTTP request is one example of a participation.

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 interactions at all.

Framework Components

Low Level Components

These components provide the infrastructure for guarding attribute access and providing hooks into the higher level security framework.


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 associated with the checker.

There are several implementation variants of checkers, such as checkers that grant access based on attribute names.


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 interactions and the global security policy.


An interaction represents zero or more principals manipulating or viewing (interacting with) the system.

Interactions also provide a single method that accepts the object and the permission of the access being checked and is used to implement the application logic for the security framework.


Stores information about a single principal participating in the interaction.

Security Policy

A security policy is used to create the interaction that will ultimately be responsible for security checking.