Portal Management

This page reviews Portal Management for GroundWork Monitor.

About Portal Management

The Administration>Portal Management portlet and sub-pages; Portal Objects, Portlet Instances, Portlet Definitions, and My GroundWork enables administrators to manage the various portal objects including themes, layouts portal instances, pages, windows, security, and deployed portlets. In this section we'll cover all of the Portal Management sub pages and securing portal objects.

Portal Management Terminology

  • JBoss Portal - The JBoss Portal unites GroundWork Monitor web applications into a common presentation framework.
  • Portal Instance - In the context of Portal Management, a Portal Instance is the top level in the hierarchy of the user interface and contains Pages, Sub Pages, Windows, and Portlets.
  • Default Portal - This is the Portal displayed upon login. The default Portal for the GroundWork Monitor system is named groundwork-monitor. By default, when a user logs in they are forwarded to the default page of the default portal. The default Page is dashboard.
  • Portal Pages - A Portal object. A Portal Page is an aggregator of Portlet Windows.
  • Sub Pages - A Portal object. Just like a Portal Instance can contain several Pages, a Page can contain several Sub Pages, and Windows.
  • Windows - A Portal object. Pages contain Windows.
  • Portlet Instances - A Portal object. Contained in a Window.
  • Portal Management - One of three tab options under the Administration Page. Portal Management enables an administrator to configure and mange the GroundWork Monitor Portal Instances. The sub options provide management options for;
    • Portal Objects - Access to Portal instances, Pages, Windows with associated actions.
    • Portlet Instances - Allows security configuration of Portlets. Grant or revoke role permissions.
    • Portlet Definitions - List of Portlets for the selected Portlet provider (e.g. local). Location to create instances to then be assigned to a Window in a Page.
    • Dashboards - Enables administrators to configure parameters for all user dashboards.
Portal Management Diagram

The diagram below maps the functionality of the management portlet by displaying the hierarchy of objects.

  • The JBoss Portal contains Portal Instances. Portal Instances for GroundWork Monitor include groundwork-monitor, svtemplate, and template.
  • The default Portal Instance is groundwork-monitor. A Portal Instance can contain several Portal Pages.
  • A Portal Page (e.g. admin, auto-disc, config, console, reports) can contain several Sub Pages and several Windows. Portal Pages enable the creation of Sub Pages and is the location where you can set which Sub Page is to be displayed when a user is first directed to the Portal Page.
  • A Sub Page (e.g default, foundationview, users) is simply a page within a page and can contain additional Pages and/or Windows. Here the Portal Management (default) page is within the Administration (admin) page of the GroundWork Monitor Portal Instance (groundwork-monitor).
  • A Window (e.g. AdminPortletWindow) contains one Portlet Instance.
  • A Portlet Instance (e.g. Administration portlet) is the content assigned to a Window.

Portal Management Pages

Portal Objects

The Portal Management>Portal Objects page is used to manage portal objects; portal instances, pages, windows and their respective configuration information. Selecting the Portal Objects page brings an administrator to a page showing a list of available portal instances [e.g. groundwork-monitor defined for the portal server.

Directly located beneath the Portal Objects tab is the navigation indicator or breadcrumbs. This provides context as to where in the hierarchy of portal objects the current screen is located as some of the screens can be found at several levels of the hierarchy. The Manage Portals section displays various system-wide action icons. The Properties action link displays the currently configured properties for this portal instance and allows you to modify them, as well as configure the error handling strategy. In the Manage sub-portals section you'll see a list of defined GroundWork Monitor portlet instances; groundwork-monitor and template. Along side each of these available instances is a list of the possible Actions (e.g. Security, Properties) that can be performed for each instance. Clicking on the portal name will display a screen showing the information for the selected portal instance, thus drilling down the hierarchy of available portal objects. Clicking on an action name will execute the specified action on the associated portal instance. These actions are also available on each individual portal screen. The notable exception is the Make Default/ Default action which is only available in this listing as it is more of an action across portals than specific to a portal. This action allows users to specify which portal instance is displayed when the portal is first being accessed. You can see the default portal is set to groundwork-monitor.

You'll find the format of object actions being listed on each initial page and then again on subsequent pages throughout Portal Management. For instance if you select groundwork-monitor from the list of portal instances you will arrive at a the portal instance page with actions that mirror the links in the previous page, then a list of associated portal pages and associated page actions.

Portlet Instances

The second Portal Management page is Portlet Instances. This page provides access to all the portlet instances that have been configured in the running portal. On this page, the user can either modify the security constraints for the portlet (to grant access only to certain roles), destroy an instance or override the portlet definition preferences for a specific instance if there is any override-able preference.

Portlet Definitions

We continue with the third Portal Management page, Portlet Definitions, which displays a list of portlet definitions formatted as a table displaying the portlet name, description and other options. Clicking on a portlet name in the list will display the portlet definition title, description, supported languages and keywords. The Preferences action (when available) is used to edit preferences at the portlet definition level.

My GroundWork Page

The last of the Portal Management pages is My GroundWork, which enables administrators to configure parameters for all user dashboards. It also allows the configuration of error pages and theme properties.

Securing Portal Objects

Portal security uses a role based access control model. 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 descriptor, or via the Administration>Portal Management page once the portal is up and running. The Portal Management page provides two sub-pages;Portal Objects and Portlet Instances. Portal Objects focus is on portals and portals pages, where Portlet Instances is portlets, instances of those portlets, and portlet windows.

The GroundWork Monitor portal server incorporates one main portal; groundwork-monitor (main application sub-pages e.g. admin and auto-disc). This portal along with its contained portal objects have assigned security constraints thus limiting access to system users at the portal level. The Security action is used to configure security based on a user's Role. A Role is a group of Users and is assigned specific access Permissions. Therefore, when a user logs into GroundWork Monitor the users associated role permissions will be active allowing specified access to portal objects based on the associated role's security constraints.

First, let's define the various roles and permissions and then we'll discuss the specific portal resources.

Roles

Permissions

The out-of-the-box GroundWork Monitor system Users include admin, operator, and user.

The out of the box GroundWork Monitor system Roles include Administrators, Operators, and Users. There are two additional roles; Authenticated and Unchecked.

  • The system user admin is a member of the Administrators (GWAdmin) role. Intended for administrators of the system and has access to the entire portal including Dashboards, Event Console, Status, Reports, Configuration, Auto Discovery, Administration, Nagios, and Resources.
  • The system user operator is a member of the Operators (GWOperator) role. This role is intended for operators of the system and is setup with access to the Dashboards, Event Console, and Status applications, along with the ability to submit actions using action portlets, utilize Nagios screens, and access product references with Resources.
  • The system user user is a member of the Users (GWUser) role. This role is intended for users of the system and is setup with access to the Dashboards, and Status applications, along with the ability to submit actions for services and hosts (using action portlets enabling a user to schedule downtime, enable/disable notifications, and enable/disable active checks), and access product references with Resources.
  • The Authenticated role in JBoss is defined as any user who has logged in is a member of the Authenticated role in addition to other roles they have been assigned.
  • The Unchecked role in JBoss is any user who has not logged in is automatically a member of the Unchecked role.

Permissions are applied to Roles. Permissions indicate each roles specific access to the current portal object. You can provide more than one security constraint per portal resource. This allows you to provide different roles with different access privileges for the same resource. Permissions are described here:

  • View - A member of the associated role can view the page of the portal object. Then View Recursive must be added to any child pages so that they can be viewed except the ones where you want to restrict access.
  • View Recursive - A system user can view the page and child pages.
  • Personalize - A system user can personalize the page's theme.
  • Personalize Recursive - A system user can personalize the page and child pages themes.
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 portlet in question.

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.

Securing Portlet Windows

To secure an individual portlet window there is a security constraint for any individual window.
Securing Pages

Analogous to the previous portal resources, pages can be secured via a security constraint as well. Selecting the screenshot image above and referring to the diagram on the right, you can see that access to the Portal Object console page (Event Console application) is limited to View Recursive permissions for the Operators role which means any member of the Operators role has access to the Event Console page and child pages.

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.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.