Search | Download | Documentation | Resources | Members

Guest

Zope Exits

Zope Newbies
Technocrat.net
Appwatch.com
CodeCatalog.com

Welcome to Zope.org

This is an early draft chapter from a forthcoming book on Zope, to be published by O'Reilly & Associates. The material has not been through O'Reilly's editorial process, nor has it been reviewed for technical accuracy. O'Reilly & Associates disclaims responsibility for any errors in this draft and advises readers to use the information contained herein with caution.

O'Reilly & Associates grants readers the right to read this material and to print copies or make electronic copies for their own use. O'Reilly & Associates does not grant anyone the right to use this material as part of a commercial product or to modify and distribute it. When O'Reilly & Associates publishes the final draft of this book in print form, the content will be made available under an open content license, but this chapter is not open content.

If you have any comments on the material in this chapter, you should send them to the authors, Michel Pelletier and Amos Latteier, at docs@digicool.com.

Users and Security

Security is a central concern for web applications. Security is not an afterthought that can be added to protect a working system. Instead security should be an important design element that you consider as you build your Zope site.

Why should you care about security? Security controls what the users of your site can do and it controls how you and others can maintain your site. If you carefully consider security you can provide powerful features to your users and allow large groups of people to safely work together to maintain your site. If you do not consider security it will be difficult to give your users power safely and managing your site will become a messy burden. Your site will suffer not only from people doing harmful things that they shouldn't be able to do, but it will be hard for you to provide value to your users and control to those who manage your site.

Zope weaves security into almost every aspect of web application building. Zope uses the same security system to control Zope management as you use to create users for your application. Zope makes no distinction between using and managing an application. This may seem confusing, but in fact it allows you to leverage a Zope's security framework for your application's needs.

Authentication and Authorization

Security in the broadest sense controls two functions, authentication and authorization. Authentication means finding out who you are, and authorization means determining what you can do. Zope provides separate facility to manage the process of identifying users and granting access to controled actions.

Zope uses User Folders to define user accounts. When you access a protected resource, Zope will ask you to log in and will look for your account in a User Folder. This is the authentication process.

Now that you've been identified, Zope determines whether or not you have access to the protected resource. This process involves two intermediary layers between you and the protected resource, roles and permissions. Users have roles which describe what they do, and Zope objects have permissions which describe what can be done with them. Security policies map roles to permissions; in other words they say who can do what. In this way Zope authorizes you to access a protected resource.

In the following sections we'll look more closely at these processes and how to effectly set security policies.

Users

Defining Users in User Folders

To create user accounts in Zope you add Users to User Folders. You should already have added a Manager user to your top level user folder.

Let's create a new user so that your coworker can help you manage your Zope site. Go to the root Zope folder. Click on the user folder, it is named acl_users:

        <screenshot user folder>

Click the "Add" button to create a new user.

This form lets you define the user. Type the a username for your coworker in the "Name" field. The username can contain letters spaces and numbers. The username is case sensitive.

Choose a password for your coworker and enter it in the "Password" and "(Confirm)" fields. Your coworker can changer their password later when they log in. You might want to use a password like "change me" to help remind them to change their password.

The "Domains" field lets you restrict Internet domains from which the user can log in. This allows you to add another safety control to your account. For example if you always want your coworker to log in from work you could enter your work's domain, for example "myjob.com", in the "Domains" field. You can specify multiple domains separated by spaces to allow the user to log in from multiple domains. For example if you decide that your coworker should be able to manage zope from their home account too, you could set the domains to "myjob.com myhome.net". You can also use IP numbers with asterixes to indicate wildcard instead of domain names to specify domains. For example, "209.67.167.*" will match all IP addresses that start with "209.67.167".

The "Roles" select list indicates what roles the user should have. In general users who are performing management tasks should be give the "Manager" role. The "Owner" role is not appropriate in most cases because one is normally an owner of a specific object, not an owner in general, as we'll see later. Later we'll also see how you can define your own roles such as "Editor", "Reviewer".

To create the new user now click the "Add" button. Now you should see a new user object in the user folder:

        <screenshot user folder>

You can edit existing users by clicking on them. You should see a form very similar to the form you used to create a user. In fact you can control all the same settings that we just discussed from this form. After your coworker logs in with the account you created for them, they should go to this management screen and change their password here (XXX This is not necessarily true, the coworker must have the Manage Users permission -M).

You should notice that it's possible for a manager defined in a given user folder to change other people's accounts defined in their user folder. This may or may not be what you want. Later we'll look at ways to avoid this potential problem. It is not, however, possible for someone to find out your password from the managment interface. Another manager can change your password, but not find out your current one.

Before we leave the subject of user folders we should also mention that you can delete existing user from a user folder by selecting the user and clicking the "Delete" button. Remember, like all Zope actions, this can be undone if you make a mistake.

Logging in and Logging Out

As you've already seen in chapter 1. you log into Zope by going to a managment URL in your browser and entering your username and password. We also pointed out in chapter 1 that because of how most web browsers work, you must quit your browser to log out of Zope.

As we'll see later there are other types of user folders besides the basic Zope user folder. Some of these other user folders provide alternate login and logout controls. Desipte this variety, all user folders use the same general login procedure.

Go to the management URL in your browser
Provide your username and password when prompted.

User Location

All this is true but it isn't the complete story (XXX confusing -M). Zope can contain multiple user folders at different locations. Users defined in a given user folder can only log in to the Zope folder where they are defined. This means that users defined in the user folder in the root folder can manage all folders. However, consider the case of the user folder in Figue XXX:

        <screenshot userfolder contents, URL
        /BeautySchool/Hair/acl_users>

The user "Ralf" is defined in a user folder at /BeautySchool/Hair/acl_users. This means that Ralf cannot log into to Zope above the folder at /BeautySchool/Hair. Effectively Ralf's view of the Zope site is limited to things in the Hair folder and beneith it.

Using this technique it's easy to build simple security policies. One of the most common Zope management patterns is to place related objects in a folder and then create a user folder in that folder to hold the accounts of the people who are responsible for those objects.

For example if your organization has a uniforms department you could create a "uniforms" folder. In that folder you could put objects such as pictures of uniforms and descriptions for how to wear and clean them. Then you could create a user folder in the uniforms folder and create an account for the head tailor. When a new style of uniform comes out the tailor doesn't have to ask the web master to update the site, he or she can update their own section of the site with out bothering anyone else.

Alternate User Folders

XXX

Super User

XXX supercannotown error

Defining the Super User: XXX zpasswd.py access

Anonymous User

XXX

Querying the User

XXX User API, accessing user from DTML

Roles

Introduction

Roles represent kinds of responsibility and authorization, such as "Manager" or "Author." Users have Roles associated with them, and Roles have Permissions associated with them. Roles provide the linkage between authentication (the user object) and authorization (what the user can do).

The roles associated with user objects can change; roles can be giveb or taken away. When a user is working with an object they may have local roles associated with them.

Local Roles

Local Roles are an advanced feature of Zope security. Users can be given special roles when working with a certain object. If an object has special local roles associated with a certain user then that user gets those additional roles while working with that object.

For example, if a user owns an object they are usually given the additional local role of Owner while working with that object.

Permissions

Permissions represent like operations on objects and provide an organized mechanism for setting access control on objects. Permissions correspond to the high-level permissions, like "View", "Delete Objects", and "Manage Users". Permissions protect the resources of objects.

Managing Security

Many objects in Zope have a Security management tab. This tab lets you manage the Permissions on an object. Let's visit the security tab on the root folder:

      <screenshot>

There is a lot going on here. In the center of the screen is a grid of check boxes. The vertical columns of the grid represent Roles, and the horizontal rows of the grid represent Permissions. Checking the box at the intersection of a Permission and a Role grants users with that Role the ability to access resources protected by that Permission.

For example, you need a site to be private and only users that have authorized themselves as customers of yours can view this Folder. To do this, first all Anonymous users View access by unchecking the View Permission where it intersects the Anonymous Role:

      <screenshot>

Adding Roles

The public can't view this folder now, but neither can your customers. For them to be able to see the folder, they must have a Role that identifies them as one of your Customers. At the very bottom of the Authorization screen there is a form to add new roles:

        <screenshot>

Put the role Customer in the text box and click Add Role. Now, there is a new vertical column on the grid that is used to map to Permissions for the Customer role. Since we want our customers to be able to View the site, check the View permission at the intersection of the Customer role and the View permission:

        <screenshot>

Acquisition

Acquisition is the mechanism in Zope for sharing information among objects contained in a folder and its subfolders. The Zope security system uses acquisition to share permission settings so that access can be controlled from high-level folders.

For example, if you had a small site with no managers, then you can set the permissions you want up in the root folder, and all the permissions below the root folder will acquire the root folder permissions.

When you site grows a little, you will want to snip off a chunk and hand off the management of that chunk to someone else. This is delegation.

The delegated manager can now define permissions in their lower chunk that override or extend the permissions you set in the root folder.

The delegated manager can also sub-delegate chunks of their chunk off to sub-delegated managers. These sub-delegated managers can then, in their sub-chunk, choose to extend or override the policies set by the delegated manager, who chooses to extend or override the security policy set by you! And so on.

We'll go through an example of delegating off chunks of Zope. Proper delegation is a powerful way for many people to manage a web site.

XXX compare restrictions by roles versus restrictions by location XXX

XXX examples of how to secure different groups of objects with new roles, local roles, object location and user location. XXX

Security Usage Patterns

A fundamental idea in Zope security is that administration should be turned over to others as you traverse the folders in a URL. The administrators at each level can define new administrators below their folder, thus passing the work down the hierarchy. To do this effectively, one must understand the four key components of Zope security: users, roles, permissions, and acquisition.

How you set up your security system in the beginning can make your delegation task easy or very complex. Because Zope's security system contains many abstractions and is so fine grained, it is easy for beginners to make simple errors. By following some simple patterns, you can create strong and useful delegation policies.

Delegation Patterns

Turning Over Control

Lets say you want to delegate the management of the Sales Folder in your Zope site over to the new sales web manager. First, you don't' want this guy messing with anything other than the Sales folder, so you don't need to add him to the acl_users Folder in the root folder. Instead, create a new User Folder in the Sales Folder:

          Create user Folder <screenshot>

Now you can add the new sales web manager user to the acl_users folder in Sales and give the user the Role Manager:

          <screenshot of add user screen>

This user can now log directly into the Sales/manage screen:

          <screenshot>

Notice how the navigation tree on the left shows that Sales is the root Folder. The manager defined in this folder will never have the ability to log into any folders above Sales so it is shown as the top folder.

Acquiring a Default Policy

Explain how default permission settings are acquired.

Extending/Overriding the Default Policy

How to not acquire a permission and extend or override the default policy.

Delegating Roles

XXX Doesn't Jeffrey have some role delegation pattern used a lot on his projects?

How to protect your site

XXX site management best practices. XXX

Ownership

When a user creates an object, they own that objects. Ownership is a low level security concept. Objects in Zope should not be able to carry out actions that their owners cannot do (XXX confusing unless Executable objects are explained first -M). If objects could do this, then a user with low privileges could trick a user with higher privileges into executing possible malicious code.

Because of this potential exploit objects never execute with more roles roles than those of their owner.

Ownership can change hands throughout an objects life. Most objects have an Ownership tab: Here is one on a Folder:

      <screenshot>

This screen tell you:

If the object is unowned.

If objects is own, who by and where they are defined

Make ownership implicit

Explicit take ownership

Security of Executable Objects

Executable objects must be executed safely. It would be a security hole if a user with lower privileges creates some DTML code that they trick a user with higher privileges to execute. Because of this, executable objects always execute with the roles of XXX

Proxy Roles

XXX

example - form & action to allow changing your password.

Security and FTP, monitor server, XML_RPC, WebDAV, etc?

XXX where does this go? XXX

If you have any comments on the material in this chapter, you should send them to the authors, Michel Pelletier and Amos Latteier, at docs@digicool.com.