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
groups of users and
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.
permission objects that can be
registered as zope.component utilities for validation, introspection,
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.
Low Level Components¶
These components provide the infrastructure for guarding attribute access and providing hooks into the higher level security framework.
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¶
Provides accessors for
setting up interactions and the
global security policy.
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
security policy is used to create the
interaction that will ultimately be responsible for security checking.