This section describes how to secure portal objects (portal instances, pages, and portlet instances), using the JBoss Portal *-object.xml descriptor OR portlet-instances.xml descriptor. View the User Guide for information on how to secure objects using the Management Portlet.

Securing portal objects declaratively, is done through the *-object.xml ( Section 6.2.1, “*-object.xml Descriptors” ), for Portal Instances and Pages, or the portlet-instances.xml ( Section 6.2.2, “The portlet-instances.xml Descriptor” ) for Portlet Instances. The portion you will be adding to each object is denoted by the <security-constraint> tag:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE deployments PUBLIC
   "-//JBoss Portal//DTD Portal Object 2.6//EN"
   "http://www.jboss.org/portal/dtd/portal-object_2_6.dtd">
<deployments>
   <deployment>
      <parent-ref>default</parent-ref>
      <if-exists>overwrite</if-exists>
      <properties/>
      <page>
         <page-name>MyPage</page-name>
         <window>
            <window-name>HelloWorldPortletPageWindow</window-name>
            <instance-ref>HelloWorldPortletPageInstance</instance-ref>
            <region>center</region>
            <height>0</height>
         </window>
         <security-constraint>
            <policy-permission>
               <action-name>viewrecursive</action-name>
               <unchecked/>
            </policy-permission>
         </security-constraint>
      </page>
   </deployment>
</deployments>

The basic principle of the security mechanism is that everything is restricted unless you grant privileges. You grant privilege on a portal node by adding a security constraint as explained here:

<security-constraint>
   <policy-permission>
      <unchecked/>
      <action-name>viewrecursive</action-name>
   </policy-permission>
</security-constraint>

The example above will grant the view privilege to anyone (unchecked role) to the current object and any child object recursively.

The security contraint portion is worth taking a look at, in an isolated fashion. It allows you to secure a specific window/page/portal-instance based on a user's role.

Role definition: You must define a role that this security constraint will apply to. Possible values are:

Access Rights: You must define the access rights given to the role defined. Possible values are:

We provide three live samples of this descriptor, here Section 6.2.2, “The portlet-instances.xml Descriptor” , Section 6.4.1, “Defining a new Portal Page” ,and Section 6.4.2, “Defining a new Portal Instance”

The JBoss Portal CMS system consists of a directory structure of Files organized unto their respective Folders. Both Files and Folders are considered to be CMS resources that can be secured based on portal Roles and/or Users.

The following features are supported by the fine grained security system of Portal CMS:

      	  	  
			   <!-- CMS Authorization Security Service -->
			   <mbean
			      code="org.jboss.portal.cms.security.AuthorizationManagerImpl"
			      name="portal:service=AuthorizationManager,type=cms"
			      xmbean-dd=""
			      xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
			      <xmbean/>
			      <attribute name="JNDIName">java:portal/cms/AuthorizationManager</attribute>  
			      <depends optional-attribute-name="Provider" proxy-type="attribute">
			      	portal:service=AuthorizationProvider,type=cms
			      </depends>         
			   </mbean>   
			   <mbean
			      code="org.jboss.portal.cms.security.AuthorizationProviderImpl"
			      name="portal:service=AuthorizationProvider,type=cms"
			      xmbean-dd=""
			      xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
			      <xmbean/> 
			      <!--
			      	NOTE: cmsRootUserName denotes a single Portal user that has access to everything in the CMS. Denote this user
				carefully and should be synonymous to the 'root' user in UNIX operating systems. By default: this value is the built-in
			      	'admin' user account. This can be changed to any other user account registered in your Portal
			      -->
			      <attribute name="CmsRootUserName">admin</attribute>  
			      <depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>     
			   </mbean>			
			   <!-- ACL Security Interceptor -->
			   <mbean
			      code="org.jboss.portal.cms.impl.interceptors.ACLInterceptor"
			      name="portal:service=Interceptor,type=Cms,name=ACL"
			      xmbean-dd=""
			      xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
			      <xmbean/>
			      <attribute name="JNDIName">java:/portal/cms/ACLInterceptor</attribute>
			      <attribute name="CmsSessionFactory">java:/portal/cms/CMSSessionFactory</attribute>
			      <attribute name="IdentitySessionFactory">java:/portal/IdentitySessionFactory</attribute>
			      <attribute name="DefaultPolicy">
			      	<policy>
			      			<!-- permissions on the root cms node -->      			
			      			<criteria name="path" value="/">
			      				<permission name="cms" action="read">
			      					<role name="Anonymous"/>
			      				</permission>
			      				<permission name="cms" action="write">
			      					<role name="User"/>
			      				</permission>
			      				<permission name="cms" action="manage">
			      					<role name="Admin"/>
			      				</permission>
			      			</criteria>
			      			<!-- permissions on the default cms node -->      			
			      			<criteria name="path" value="/default">
			      				<permission name="cms" action="read">
			      					<role name="Anonymous"/>
			      				</permission>
			      				<permission name="cms" action="write">
			      					<role name="User"/>
			      				</permission>
			      				<permission name="cms" action="manage">
			      					<role name="Admin"/>
			      				</permission>
			      			</criteria>      			
			      			<!-- permissions on the private/protected node -->
			      			<criteria name="path" value="/default/private">
			      				<permission name="cms" action="manage">
			      					<role name="Admin"/>
			      				</permission>
			      			</criteria>
			      	</policy>
			      </attribute>
			      <depends optional-attribute-name="AuthorizationManager" proxy-type="attribute">
			      	portal:service=AuthorizationManager,type=cms
			      </depends>            
			      <depends>portal:service=Hibernate,type=CMS</depends>
			      <depends>portal:service=Module,type=IdentityServiceController</depends>      
			   </mbean>
      	  

      					      
			    <mbean
			      code="org.jboss.portal.cms.security.AuthorizationProviderImpl"
			      name="portal:service=AuthorizationProvider,type=cms"
			      xmbean-dd=""
			      xmbean-code="org.jboss.portal.jems.as.system.JBossServiceModelMBean">
			      <xmbean/> 
			      <!--
			      	NOTE: cmsRootUserName denotes a single Portal user that has access to everything in the CMS. Denote this user
				carefully and should be synonymous to the 'root' user in UNIX operating systems. By default: this value is the built-in
			      	'admin' user account. This can be changed to any other user account registered in your Portal
			      -->
			      <attribute name="CmsRootUserName">admin</attribute>  
			      <depends optional-attribute-name="IdentityServiceController" proxy-type="attribute">portal:service=Module,type=IdentityServiceController</depends>     
			   </mbean>			
			   
      			

JBoss Portal relies on Java Platform, Enterprise Edition (Java EE) for the authentication of users. The Java EE authentication has its advantages and drawbacks. The main motivation for using Java EE security is the integration with the application server and the operational environment in which the portal is deployed. The servlet layer provides already the authentication functionality and obviously it is not a responsibility of the portal. Whenever a user is authenticated by the servlet layer its security identity is propagated throughout the call stack in the different layers of the Java EE stack. The weaknesses are the lack of an explicit logout mechanism and the lack of dynamicity in the mapping of URL as security resources. However JBoss Portal improves that behavior when it is possible to do so.

JBoss Portal defines a framework for authorization. The default implementation of that framework is based on the Java Authorization Contract for Containers (JACC) which is implemented by J2EE™ 1.4 Application Servers. This section of the documentation focuses on defining the framework and its usage and is not an attempt to define what authorization is or is not because it is out of scope of this context. Instead we will try to straightforwardly describe the framework and how it is used. No specific knowledge is expected about JACC although it is a recommended read.

public interface AuthorizationDomain
{
   String getType();
   DomainConfigurator getConfigurator();
   PermissionRepository getPermissionRepository();
   PermissionFactory getPermissionFactory();
}
            

<?xml version="1.0" encoding="UTF-8"?>
<server>
   ...
   <mbean
      code='MyService"
      name="portal:service=MyService">
	   <depends
         optional-attribute-name="PortalAuthorizationManagerFactory"
         proxy-type="attribute">portal:service=PortalAuthorizationManagerFactory</depends>
      ...
   </mbean>
   ...
</server>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE portlet-app PUBLIC
   "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
   "http://www.jboss.org/portal/dtd/jboss-portlet_2_6.dtd">
<portlet-app>
   ...
   <service>
      <service-name>PortalAuthorizationManagerFactory</service-name>
      <service-class>
      org.jboss.portal.security.spi.auth.PortalAuthorizationManagerFactory
      </service-class>
      <service-ref>:service=PortalAuthorizationManagerFactory</service-ref>
   </service>
   ...
</portlet-app>

PortalAuthorizationManager pam = factory.getManager();
PortalObjectId id = page.getId();
PortalObjectPermission perm = new PortalObjectPermission(id, PortalObjectPermission.VIEW_MASK);
if (pam.checkPermission(perm) == false)
{
   System.out.println("Current user is not authorized to view page " + id);
}

public interface DomainConfigurator
{
   Set getSecurityBindings(String uri);
   void setSecurityBindings(String uri, Set securityBindings)
           throws SecurityConfigurationException;
   void removeSecurityBindings(String uri) throws SecurityConfigurationException;
}

RoleSecurityBinding binding1 = new RoleSecurityBinding(Collections.singleton("view"), "Admin");
RoleSecurityBinding binding2 = new RoleSecurityBinding(Collections.singleton("view"), "User");
Set bindings = new HashSet();
bindings.add(binding1);
bindings.add(binding2);
configurator.setSecurityBinding(pageURI, bindings);