[Zope3-dev] Re: Security Model

[Jim Fulton]

Florent Guillaume wrote:
> Jim wrote wrote:
> 
>>I'll just note that an upcoming project will be to refactor the
>>authorization system in a way that should make it much more obvious
>>how to implement the sorts of systems sketched out in this thread.
>>
>>This is a possible project for the F12g sprint in January.
>>
>>As a matter of jargon, I see Zope 3's security system as consisting
>>of 4 parts.
>>
>>1. A system for declaring the permissions needed to access
>>    names in objects or classes of objects. I don't have a good name
>>    for this. (Security requirements? Permission requirements?)
>>
>>2. A system for enforcing permission requirements. This is implemented
>>    via security proxies.  In the future, it may involve a combination of
>>    security proxies and code manipulation.  I think a good name for
>>    this might be the protection system.
>>
>>    This system is somewhat pluggable through checker components, which are
>>    used to define the actual rules used by security proxies.
>>
>>3. A system for assigning principals to requests. This is the authentication
>>    system.  It is pluggable through the provision of authentication services.
>>
>>4. A system for deciding whether principals have permissions.  This is
>>    the authorization system.  It is pluggable through the provision of
>>    a security proxy and associated infrastructure (registered components)
>>    to manage authrization data. Different security policies will require
>>    different data, depending on the underlying model.
> 
> 
> In PluggableUserFolder we have found it important to separate
> authentication in two phases that may be treated by different pluggins:
> 
>    * Identification: The way the client tells the server who the
>      user is. When it comes to web, this is typically methods like
>      Basic HTTP Authentication, Cookies or SSL Certificates.
> 
>    * Authentication: Making sure the user is who he/she is. This typically
>      involves looking up the user in a user database and validating the users
>      password.

This is handled in the pluggable auth service by dividing this responsibility
between two components:

- A principal source is responsible for storing principal identifications
   and data needed for authentications, and for determining the aithenticated
   principal, if any, based on credentials (e.g. passwords) extracted from a request.

- A view on a pricipal source (multi-adapter from principal source and request) that
   extracts the credentials from the request.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org