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 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.
High Level Components¶
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.