The following article describes conceptually how the Viewpoint Security Model is structured.

Each Viewpoint portlet can specify its own security model, based on these three concepts:

  • Domain
  • Permission
  • Dependency
  • Resource

This is best explained via an example. Let's look at the Permissions tab in the Viewpoint Role Manager portlet. There are two installed portlets, Calendar and System Health. The screen looks something like this:

Calendar Permissions:

System Health Permissions:

So, in the VISA terminology, we have the following:

Domain: 'Calendar' and 'System Health' are both instances of a domain. Typically there is a one-to-one mapping between a portlet and a domain. A portlet must declare a domain with the same id as the portlet, and may optionally declare additional domains.

Resource: In the screenshot, System Health has several registered resources, such as "ADEA2" or "biggulp". A resource is an item which can have distinct security policy attached to it. For the System Health domain, each resource represents a Teradata database that is being monitored, but a resource can in fact represent an item of any type. For example, a resource could represent a URL, or a query, or a person, etc. In the screenshot above, the Calendar domain does not have any registered resources.

Dependency: A domain can depend on a permission in another domain, such that a permission in the depending domain will never be granted unless the specified permission in the depended-upon domain is granted. This allows VISA to effect logic such as: the kill_query permission in the QueryMonitor domain for the 14a1f system is not granted, because a dependency exists on the view_system permission in the TeradataSystems, and view_systems is not granted.

Permission: A permission is a named action, such as "create event" or view "detail". There are two types of permissions:

  • domain-permission
  • resource-permission

A resource-permission applies to a specific registered resource (e.g. a particular Teradata system such as ADEA2), while a domain-permission applies generally. For example, "create event" in the Calendar domain is a domain-permission, because one either has the permission or not. In contrast, view "detail" in the System Health domain - while the developer could have declared it to be a domain-permission - is declared as a resource-permission. This allows the Viewpoint administrator to grant Bob permission to view "summary" and view "detail" on the ADEA2 system, but no permissions whatsoever for the "biggulp" system. If the view "detail" had been declared a domain-permission, then it would have been an all-or-nothing situation: either Bob had permission to view "detail" for all systems, or for none at all.

Specifying your domain

A VISA domain can be created programmatically via the VISA API, but typically the domain is declared in a portlet's viewpoint-portlet.xml file. See the reference for details of the XML format. A domain is a static entity, in that it is declared once, and does not change at runtime, or indeed over the lifetime of a portlet. A domain consists of these static elements:

  • id: _a unique id
  • permissions: optional a set of permissions, zero or more; the permissions in the set are unique by name
  • dependency: optional specify if this domain depends upon a permission in another domain

Registering resources dynamically

Although the domain, permission and dependency elements of your domain model are specified statically, that generally is not true for the resources you wish to secure. In the System Health domain above, the developer of the domain did not know ahead of time what resources would be secured. It is the responsibility of the portlet or code that initially creates the resource to go ahead and register the resource with VISA, via Registry API. This might look something like:

Domain mypets = new Domain("MyPets");
Resource mycat = new Resource(mydomain, "fluffy");


Now that you've added mycat via the Registry, it will show up as an individually-permissionable item in the Role Manager. Note also that you as the developer have responsibility for managing the lifecycle of your resource; that is, don't forget to delete the resource from the Registry when the time comes.