6.2. Portal Security and Permissions
Portal Server has been designed with ease-of-use as a primary goal. For that reason, much of Portal Server is self-explanatory — a few minutes spent clicking around on the local admin page within a test portal is usually enough to acquaint a new user with the system.
As straightforward and understandable as the administration interface is for setting permissions on a portal, it is still very important to be familiar with the underlying security policies for Portal Server.
This section is intended to address those policies. We'll start by explaining some basic policy issues and defining some terms as they are used in Portal Server. Then we'll delve into the differences between the types of portals and how that affects security, and finally discuss some specific security issues in terms of permissions.
6.2.1. Permissions Terminology
This section provides definitions for the specific terminology used in defining permissions in Portal Server. A common understanding of terminology is an important piece in establishing a working permissions structure. Security issues and stumbling blocks can be avoided by ensuring that all application administrators are working from this common understanding.
Every system has a Universal administrator, who has unlimited power on the Portal Server deployment. This user account is established in the com.arsdigita.kernel.Initializer section of the enterprise.init.
Registered users of the system are created by the Universal administrator, by navigating to the site wide admin page, and choosing the Manage Users and Groups link, and then selecting the Create New User link.
Permissions are delegated to parties registered on the system. A party can be one person or it can be a group. Every user on the system is a member of at least one party, with themselves the sole member. For example, the user user1 is a member of the group user1.
Groups are collections of parties. Because groups are also parties, groups can contain other groups.
Privileges are types of permissions granted to parties. Permissions available on the default deployment are read, write, and manage:
Read provides the ability to view objects on a system (through a portal).
Write allows a party to update an existing object in the system.
Manage allows a party to create and delete objects on the system.
A role is a class of users within a group. The class of users who have a given role within a group are treated as a party, so that permissions can be assigned to a role within a group. Roles effectively partition a group into members with similar permissions.
6.2.2. Considering Permissions and Security
In practice, although there are many varying use cases for specific portal instances, there are really only three types of portals in terms of permissioning: top-level portals, personal portals, and child portals.
Top-level portals — these portals have no parent. They are mounted directly beneath the root of your web app context. They are created at the site wide admin page. When a new top-level portal is created, it is created with a members group. This group is initially empty. By navigating to the new portals local admin page and selecting the People tab, registered members of the system can be added to the members group for that portal.
Personal portals — these portals are created the first time a new user logs onto the system. A check is made, and if no Personal Portal exists for the user, one is created. All Personal Portals are mounted beneath the personal node, and are created with a members group containing the new user.
Child portals — these portals are created within an existing portal's local admin page on the Related Portals tab. The creator of a child portal is given the option in the UI to choose whether or not the new Child Portal will inherit permissions from the Parent Portal. When the inherit permissions option is chosen, the privileges members of the parent portal enjoy will be available to them in the new child portal. The members group of the child portal is also added to the members group of the parent portal, forming a two-way relationship between members of each portal.
When a creator of a child portal chooses not to inherit permissions from the parent portal, then members of the parent portal will enjoy no privileges in the child. Only the parent portal member who is creating the child portal will be added to the new child portal's member group. Individual members of the parent portal can be explicitly added to the child portal as participants or members through the People tab in the admin UI for the child portal.
Caution When choosing not to inherit permissions during the creation of a child portal, the inheritance association between the two portals is only removed one way: from parent to child. The members group of the child portal is still added to the parent portal's member group. If desired, the child portal's member group can be explicitly removed from a parent portal's member group, effectively severing the permissions association between the two groups completely.
Not understanding this policy could inadvertantly lead to a security vulnerability. For example, Portal A's admin creates a new child Portal B with the No Inheritance option selected. Then an admin for Portal B adds a registered user C to the members group of Portal B. Now C has membership in Portal A. This policy can be extermely useful, and in practice, it is expected that this policy will be desired for most child portal's. It is imperitive, however, that Portal Server administrators understand this policy. The policy can also be overridden easily when desired.