Security Constraints are applied to pages and folders. Security Constraints either grant or deny access to pages and folders. Constraints can be defined in one of three places:
Grants are associated with permissions, authorizing, or granting, a principal list access to a page or folder. A granting security constraint is the association of a list of one or more security principals combined with one or permissions. Grant constraints grant access to a page or folder for the associated list of permissions.
A deny security constraint is declared with one or more security principals; with no associated permissions. Deny constraints prohibit access to the page or folder for the given list of principals. Note that deny constraints must be listed before grant constraints.
When working with pages and folder resource constraints, a constraint can be either a declarative constraint or a referential constraint. Declarative constraints are declared and put to use right in place for the particular page or folder resource. Where as referential constraints refer to a constraint declared in a centralized security constraint resource: the page.security file. Each site or subsite can have one page.security resource for declaring constraints to be referenced in any page or folder.
A security constraint is an XML element found in a PSML file, a folder metadata file, or inthe global security declarations. A security constraint has one attribute: the name. A security constraint has the following elements:
The first four elements (roles, groups, users, owner) all define the principals who will either have a permission granted or denied.
Permissions are the portal modes that are granted by the security constraint. Note that permissions are only granted, not denied. The view permission is similiar to the read permission found in operating systems. The edit permission is similiar to the write permission found in operating systems. The help permission is similiar to the info permission found in some portals.
Constraints can be granted to one or more role principals for a set of permissions on a given resource. Roles are derived from the authorized users list of role principals, i.e. the roles that the user is a member of. If the authorized user is a member of any of the listed roles, the permission to the resource will be granted.
Constraints can be granted to one or more group principals for a set of permissions on a given resource. Groups are derived from the authorized users list of group principals, i.e. the groups that the user is a member of. If the authorized user is a member of any of the listed groups, the permission to the resource will be granted.
Constraints can be granted to one or more user principals for a set of permissions on a given resource: The current user must be one of the listed principals in the comma-separated list in order to grant permission to the resource.
Note that you can grant or deny permissions to a collection of one or more principal types. For example, here we grant view and edit permissions to the roles (manager, developer), and to the groups (QA and Research), and to the particular user (dilbert): If the authorized user is a member of any of the listed roles, groups, or users, the permission to the resource will be granted.
Constraints can also deny combinations of principals access to the entire resource. If the authorized user is a member of any of the listed groups, roles or users, all access to the resource is denied.
Declarative constraints are declared in the page.security file of the root of a site or subsite. Declarative constraints are referenced in pages and folders with the security-constraints-ref tag. Global constraints are also declarative constraints. They are also defined and found in the page.security file in the root PSML repository. The difference with global constraints is that they implicitly apply to all folders and pages within the scope of the page.security file, (i.e. the site). Note that there can be more than one page.security files in a subsite Jetspeed installation.
Folder Security constraints are placed in a
Note that all security constraints must be placed within a security-constraints collection.
Page Security constraints are placed
Note that all security constraints must be placed within a security-constraints collection.