Chapter 10. Security
Prev |  | Next

## Chapter 10. Security

### Martin Holzner

`<mholzner@novell.com>`

## 10.1. Introduction

New in version 2.2, a role based access control model was introduced into the portal. As before, all portal resources are not secured by default. However, they can be protected via security constraints that tie a role and allowed actions to the resource. Portal resources are portlets, instances of those portlets, portlet windows, portal pages, and portals. As long as there is no security constraint defined for a resource, full access is granted to every user. Once a constraint is defined, only the allowed actions from that constraint are allowed for the roles defined in the constraint. All other access is denied. Access is checked from the top down, so that if a user has no access privileges to a portal, none of the pages are accessible either, and so on.

There are two ways to define security constraints for portal resources. Constraints can be defined in the relevant deployment desciptor, or via a management UI that is provided to admins, once the portal is up and running. To define a constraint that is active immediately after the portal is deployed, once can add a security constraint tag in the relevant descriptor.

The relevant descriptors are:

- jboss-portlet.xml
- *-object.xml

Here is an example of a constraint to secure access to a page and only allow members of the 'Admin' role to 'view' the page (taken from a *-object.xml descriptor):

               <deployment>
                  <if-exists>keep</if-exists>
                  <parent-ref>default</parent-ref>
                  <page>
                     <page-name>management</page-name>
                     <window>
                        <window-name>NavigationPortletWindow</window-name>
                        <!-- more window defs here -->
                     </window>
                     <security-constraint>
                        <policy-permission>
                           <role-name>Admin</role-name>
                           <action-name>view</action-name>
                        </policy-permission>
                     </security-constraint>
                  </page>
               </deployment>

To complete the example, here is a snipped from a jboss-portlet.xml descriptor constraining access to the PolicyConfiguratorPortlet to the Admin role, allowing only to view the portlet.

                <portlet>
                   <portlet-name>PolicyConfiguratorPortlet</portlet-name>
                   <security-constraint>
                      <policy-permission>
                         <role-name>Admin</role-name>
                         <action-name>view</action-name>
                      </policy-permission>
                   </security-constraint>
                </portlet>

To achieve the same results after the portal was deployed, one can login with an Admin role, and navigate to the management tab. There navigate to the desired portal resource in the tree, and click the security menu image. Pick from the offered Roles and actions and save your choice. The changes will immediately be active. Note that you can provide more then one security constraint per portal resource. This allows you to provide different roles with different access privileges for the same resource.

## 10.2. Securing Portlets

In order to not have to limit access to each instance or window of a particular portlet, the portal offers the possibility to secure the portlet itself. All children (instances and/or windows) will then automatically be secured as well. To secure a portlet add a security constraint to the jboss-portlet.xml entry for the portlet in question, and provide the desired role and action information. Of course, this function can be delayed until the portlet is deployed. The portlet can also be secured via the management UI.

## 10.3. Securing Portlet Instances

To allow to secure all portlet windows that point to the same portlet instance with one constraint, the portal allows to define a constraint for a portlet instance. The constraint can be provided via the instance definition in the *-object.xml descriptor, or after the portlet is deployed via the management UI. The result is the same: all portlet windows of this instance will be protected.

## 10.4. Securing Portlet Windows

To secure an individual portlet window, the *-object.xml descriptor allows to provide a security constraint for any individual window.

## 10.5. Securing Pages

Analogous to the previous portal resources, pages can be secured via a security constraint as well.

## 10.6. Securing Portals

If an entire portal needs to be secured, one security constraint placed for the portal will take care of that. All pages, and portlet windows will be secured automatically as well.

Prev | Up | Next
Chapter 9. Forums Portlet | Home | Chapter 11. Clustering Configuration