Instruments of access control

eZPublish provides several instruments to control

1. a user's access to the system (authentication)
2. what a user can do once he or she is logged in (authorization)

The following list comprises these various instruments:

• Site access login prerequisite statements
• Management of users and user groups
• Policy omit statements in site.ini.append
• Site access rule statements in site.ini.append
• Roles, policies and policy limitations

With the access control framework mentioned above you may deploy almost any conceivable authorisation regime you like.

In the following passages, you find

1. a short general description of each instrument's design goal in order to help you decide when to use it and when to better avoid it.
2. use cases for typical authorisation problems and possible solutions with single or combined instruments of the access control framework.

User Authentication Management

... soon to come ;-)

Authorization Management

We distinguish two kinds of instruments to manage authorization issues with eZPublish 3, i.e.

1. Instruments to control the availability of system resources. These are Policy Omit Statements and Site Access Rules.
2. The Role and Policy Framework

Policy Omit Statements

The general method to grant unlimited access to a system resource is to declare a policy omit statement in site.ini.append files for all or only for specific site accesses.
With a policy omit statement, you simply switch off the role and policy-based authentication control framework for a given system function. Hence a policy omit statement allows everyone to access the resource irrespective of his or her user rights.
Policy omit statements are not designed to be used extensively. They are there for two rather pragmatic reasons:

1. To avoid deadlocks in authentication. A deadlock would occur if e.g. you require everybody to log in and have forgotten to exclude the user login function itself from the prerequisite of being logged in.
2. to speed up the system in service requests designed to be accessable for the world. If e.g. you have no reasons to restrict universal read access to all pieces of content you ever provide in your public site access, then you may well consider to place a policy omit statement like this
   PolicyOmitList[]=content/read
   in the site.ini.append of your public site access directory. This will boost overall system performance and is better than a comparable zero-policy-limitation rule in role definitions for anonymous users, since the former does not trigger any authentication check at all, while the latter does.

With these two fields of application for Policy Omit Statements in mind, you should generally use them to grant unlimited access to the following system functions, even if you are going to setup a rather paranoic authorization regime later on:

PolicyOmitList[]=user/login
PolicyOmitList[]=user/logout
PolicyOmitList[]=user/success
PolicyOmitList[]=layout
PolicyOmitList[]=ezinfo

Place these statements in your - global - site.ini.append file (settings/override - directory), if you don't have good reasons to make more sophisticated use of Policy Omit Statements in different Site Access - definitions.

Site Access Rules

In contrary to policy omit statements, site access rules are the general instrument to prevent access to system resources.

... more to come soon ;-)

Roles, Policies and Policy Limitations

Roles apply a set of policies to a set of users and/or user groups.

A policy depending on the module, can dictate access to module level and sometimes function level. Each policy can apply to a particular Subtree, Node, or a Section; or a combination there-of.