Chapter 10. Security - JBoss Portal 2.2 User Guide 英文版用户使用指南文档

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.

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.

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.

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.

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

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

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.