Chapter 13. Security. IBM Version 3 Release 5.0

Chapter 13. Security

Security controls access to application features and business objects.

Security elements

In its most general sense, security is something that prevents bad things from happening while allowing good things to happen. As it applies to the IBM

TRIRIGA Application Platform, security is what allows users to look at or manipulate data they should be looking at or manipulating, while preventing users from looking at or manipulating data they should not be.

The following lists the main facets to security on the IBM TRIRIGA Application

Platform:

Authentication

This involves users identifying themselves to the IBM TRIRIGA

Application Platform and then doing something else to prove that they really are who they claim to be.

Licenses

A license allows a user to access specific features of an application or to use tools that are provided by the IBM TRIRIGA Application Platform. A license is useful for controlling access to applications and tools. It is not helpful for controlling access to records.

Groups

A group is a list of users and of other groups. A user can belong to more than one group.

Access Permissions

Access permissions determine what kinds of records the members of a group can access and what they can do with the records.

Organization and Geography

You can use a record's organization and geography to control which users can access the record.

Project

The project that is associated with a record can restrict who is able to view or modify the record.

The basic rule of IBM TRIRIGA Application Platform security is that a user can look at something or perform an action only if the user belongs to a group that has permission to do so.

Authentication

Authentication requires users to identify themselves to the IBM TRIRIGA

Application Platform and then do something else to prove that they really are who they claim to be.

Setting up authentication for a user involves two steps: v Create a record that describes the user.

© Copyright IBM Corp. 2011, 2015

439

v Create an embedded My Profile record that describes the user's user ID and how the user interacts with the IBM TRIRIGA Application Platform.

The typical procedure for creating a record that describes a user is a manual procedure. Navigate to Portfolio > People. Here you can create triPeople records by using the Employee, Consultant, or External Contact forms. You also may configure other types of records to describe users.

The forms for these records have a number of tabs. After you have filled in the required fields on the General tab, you are ready to fill in the details of the My

Profile record that describes the user ID to the IBM TRIRIGA Application Platform and the way the user interacts with the platform.

You can create the My Profile record indirectly by going to the Profile tab of the record you just created. The fields on the Profile tab have these meanings:

User Name

This is the user ID that the user uses to sign in to IBM TRIRIGA. This field must be filled in even though the form does not indicate that it is required.

There is no field to set the user's initial password. Unless modified in your implementation, the password for a new user is password.

Active TRIRIGA User?

Select this check box if you want the user to be able to sign in.

Initial Pwd Reset

When this check box is selected, the first time this user signs in to IBM

TRIRIGA the user is prompted to change their password.

Home Page

Defines the main window, or portal, the user sees when the user first signs into IBM TRIRIGA when at the Company Level. This also displays whenever the user clicks the Home menu item. If this value is blank, IBM

TRIRIGA renders a default portal. See the IBM TRIRIGA Application

Platform 3 User Experience User Guide for more information about portals.

Menu

A navigation collection that defines the structure and content of the menu bar at the top of page when at the Company Level. See the IBM TRIRIGA

Application Platform 3 User Experience User Guide for more information about navigation collections and menus.

Project Home Page

Similar to Home Page, but only applies when the user is working in a

Project context.

Project Menu

Similar to Menu, but only applies when the user is working in a Project context.

Sitemap?

If this check box is selected, a Sitemap link is available for this user. The sitemap displays a site index that contains all of the selectable navigation items based on the user's menu. Note that navigation items can be configured to only appear on the sitemap, and hence would be unavailable to users that do not have the Sitemap check box selected. See the IBM

TRIRIGA Application Platform 3 User Experience User Guide for more information about sitemap and navigation items.

440

© Copyright IBM Corp. 2011, 2015

Disable Company Level?

Normally you leave this cleared. If this check box is selected, the Clear

Project button is disabled for the user. This works in conjunction with application features that populate the last project used. The project selector enables the user to move between projects, but without the Clear Project button, the user cannot exit a project and go to the Company Level.

User Language

The value of this field is the language that the user prefers to use, such as

US English, Spanish, French. The value of this field determines which set of labels and other text the user sees.

The list of languages that you can choose from in this field is determined by a list named Language.

For more information, see the IBM TRIRIGA Application Platform 3

Globalization User Guide.

Currency

Use this field to specify the default currency for the user. For more information, see the IBM TRIRIGA Application Platform 3 Globalization User

Guide.

Time Zone

The time zone that the user is normally in. If blank, the time zone is from the time zone in which the application server is running.

Delegate To

The purpose of this field is to allow another user to handle this user's approval action items when this user is not able to do it. If this field has a value, it is the user allowed to approve action items on behalf of this user.

Approval Amount

The maximum amount that this user is authorized to approve on a single transaction.

Enable Accessibility Mode

When selected, metric reports are displayed in tabular format by default.

The user can switch to chart format.

Also when selected, schedule assumptions in a capital project form are shown in a separate Schedule Assumptions tab instead of in the Schedule tab.

Enable Skip Navigation

When selected, the Skip Navigation link is displayed at the top of portals and forms. After the user tabs to the Skip Navigation link and presses

Enter, the user is taken directly to the main content area.

Group Details

The groups the user is in.

License Details

The licenses the user has.

Having filled in the fields of the Profile tab, you are ready to create the user's My

Profile record by clicking the Activate action. After the My Profile record is created, the user can sign in to IBM TRIRIGA.

Chapter 13. Security

441

By default, the platform logs successful and failed logins and user account changes in the security.log file. You can turn off this logging by editing the log4j.xml file located in the <IBM TRIRIGA installation>\config folder (for example,

C:\Tririga\config\log4j.xml

).

Being able to sign in is not useful by itself. If no licenses are granted to a user, the user cannot access any application features or tools provided by the platform. User

IDs that have not been granted any licenses are not allowed to sign in.

Having licenses without membership in a group is not useful either. In order to be able to access any record, a user must have permission to do so. To perform an action on a record, a user must have permission to perform the action on the record. A user gets permissions by being a member of a group that has the permissions.

Other triPeople business objects

If using a record created from a triPeople business object is not appropriate for your application, you can create and use another business object in the triPeople module.

The business object must have an association with the My Profile business object.

The association must be named Associated To on both ends.

The form should have a Profile tab similar to the one in the Consultant, Employee, or External Contact form. The Profile tab should have an action on it that allows a

My Profile record to be created that describes the user's user ID.

The easiest way to accomplish these things is to copy what already exists. Create the new business object by copying the triPeople business object. Copy the corresponding form to create the new form.

Passwords

IBM TRIRIGA supports strong passwords. Using strong passwords lowers the overall risk of a security breach. Define your company's implementation in Tools >

System Setup > System > Password Setup.

The system only uses the rules defined in the rest of the Password Setup form when the Enforce Password Rules field is selected. When Enforce Password Rules is not selected, which is the default value, the system uses the standard IBM

TRIRIGA password rules and ignores the rest of the values in the Password Setup form.

The system begins to follow the rules defined in the Password Setup as soon as the record is in Active status.

Single sign-on

The IBM TRIRIGA Application Platform's authentication mechanism is designed to work with most single sign-on mechanisms. There is more than one way to integrate the IBM TRIRIGA Application Platform's authentication mechanism with single sign-on mechanisms. The essence of how it works is that the IBM TRIRIGA

Application Platform learns from an external trusted source the user ID of the user

442

© Copyright IBM Corp. 2011, 2015

to be logged in to the platform. If the user ID from the external source matches a user ID specified by a My Profile record, then the platform accepts the user ID as authenticated and logs the user in.

The details of how to integrate the IBM TRIRIGA Application Platform authentication mechanism with a single sign-on mechanism are described in the

IBM TRIRIGA Application Platform 3 Single Sign-On Setup User Guide.

License management

A license allows access to business objects, tools, and their corresponding menu items in the IBM TRIRIGA Application Platform. When an IBM TRIRIGA product is purchased, one or more license files are made available to give access to the combination of objects and tools provided by each license.

You obtain licenses by buying them. You buy the kinds of licenses you need in the quantity that you need and install them in your IBM TRIRIGA Application

Platform environment. After you install the licenses, they are in your <IBM TRIRIGA installation>\config\licenses folder.

The licenses are listed in Tools > System Setup > System > Licenses. For each license, you can see whether it is active in the system.

Users cannot take advantage of a license unless it is assigned to them. To assign licenses to users, use the License Manager in Tools > Administration.

Three kinds of licenses may appear in the License Manager.

v Product licenses that allow users to access features of IBM TRIRIGA application products. A user ID cannot sign in to the IBM TRIRIGA Application Platform environment unless it has been assigned at least one product license.

v Platform licenses that determine the features or environment for which a IBM

TRIRIGA Application Platform environment is configured. These affect the platform environment as a whole. They do not have any direct relationship to what an individual user ID may do.

v An IBM TRIRIGA Custom Application license is a special kind of product license that does not provide access to any application features. However, assigning a custom application license to a user allows that user to sign in and use applications that were not created by IBM TRIRIGA.

The left side of the License Manager is a list of available licenses. When you select the radio button to the left of a license's name, in the right side of the License

Manager you see the user IDs to which the license has been assigned.

You can add user IDs to the list by clicking the Add Users action. You can remove user IDs from the list by selecting the check box next to a user ID and clicking the

Delete Users

action.

The query on the Add User action can be customized. To have the system run your query, name your query "Security License List" in the Report Manager.

The licenses shown in the License Manager are synchronized with the licenses shown in user profiles. Adding a user to the License Manager triggers a workflow to update the user's profile record. Deleting a user from the License Manager triggers a workflow to remove the license from the user's profile record.

Chapter 13. Security

443

When you need to change the licenses or security groups assigned to more than a few users, you can use the Bulk Security Utility to update many users at once. The

Bulk Security Utility is in Tools > Administration.

IBM TRIRIGA Application Platform license

You need an IBM TRIRIGA Application Platform license to create or modify business objects or to create or modify a workflow.

Attention:

Be extremely careful to whom you assign an IBM TRIRIGA

Application Platform license. An IBM TRIRIGA Application Platform license allows a user to circumvent all platform security features.

Groups

A group identifies a set of user IDs and the access that the group has to records and what can be done with the records.

Groups are managed by the IBM TRIRIGA Application Platform's Security

Manager. To access the Security Manager, navigate to Tools > Administration >

Security Manager.

IBM TRIRIGA provides a number of predefined security groups corresponding to roles our customers commonly have. Use these security groups as a starting point to meet your company's specific security needs.

You can create a new group by clicking the Add action. Click the hyperlinked name of a group to edit it. To delete a group, select the check box next to the group's Name and click the Remove action.

After you add, update, or delete a group, clear the Security Scope cache in the

Administrator Console. For more information about the Administrator Console, see the IBM TRIRIGA Application Platform 3 Administrator Console User Guide.

When you use a group other than the Admin Group to control access to the

Document Manager, you must include the group in the ROOT document record and the group must have at least edit access.

The form for a group has three tabs that are used for security purposes: v General v Members v Access

General tab

The General tab has two sections that are labeled General and Data Access.

Here are descriptions of the fields in the General section.

Name

The text in this field is the name of the group.

Description

This field contains a description of the group.

Personalize Portal

444

© Copyright IBM Corp. 2011, 2015

If Yes, users in this group can select Personalize on their portal, which allows them to customize their Home page. If No or empty, the Personalize button is not available to users in this group.

For information about how users can personalize portals, see the Getting

Started videos in the Media Library at https://www.ibm.com/ developerworks/community/wikis/home?lang=en#!/wiki/

IBM+TRIRIGA1/page/Media+Library.

Personalize Bookmarks

If Yes, users in this group can select Add to Bookmarks and personalize their Bookmarks menu. If No or empty, bookmarking is not available to users in this group.

For information about how users can personalize bookmarks, see the

Getting Started videos in the Media Library at https://www.ibm.com/ developerworks/community/wikis/home?lang=en#!/wiki/

IBM+TRIRIGA1/page/Media+Library

Ignorable For Nav. Overrides

If Yes, the group is excluded from consideration in Group Overrides in a

Navigation Collection.

If No or empty, the group is included in Group Overrides in a Navigation

Collection.

See "Navigation Collections" in the IBM TRIRIGA Application Platform 3

User Experience User Guide for more information about Group Overrides.

Access All Profiles

If Yes, users in this group can access their own My Profile record or another user's My Profile record.

If No or empty, users in this group can access their own My Profile record but cannot access another user's My profile record. This is the default value.

The ENABLE_PROFILE_ROW_LEVEL_SECURITY property in

TRIRIGAWEB.properties must be set to Y for the value of Access All

Profiles to control user security access to My Profile records. For information about the properties files, see the IBM TRIRIGA Application

Platform 3 Installation and Implementation Guide.

Here are descriptions of the fields in the General tab's Data Access section.

System Organization

If the value of the group System Organization field is blank, members of the group have access to records with blank System Organization fields.

And, members of the group do not have access to records with values in their System Organization fields.

If the value of the group System Organization field is not blank, members of the group have access to records with values in their System

Organization fields at the same level or at a lower level in the

Organization hierarchy. If the value of the group System Organization field is \Organizations, members of the group have access to records with blank

System Organization fields. If the value of the group System Organization field is not blank and not \Organizations, and the record's System

Chapter 13. Security

445

Organization field is blank, members of the group have access to records in queries but do not have access to records in forms.

If you do not intend to use groups to restrict access to or visibility of records, and records have values in their System Organization fields, then set the value of the group System Organization field to \Organizations.

This is discussed in greater detail in "Organization and geography".

System Geography

If the value of the group System Geography field is blank, members of the group have access to records with blank System Geography fields. And, members of the group do not have access to records with values in their

System Geography fields.

If the value of the group System Geography field is not blank, members of the group have access to records with values in their System Geography fields at the same level or at a lower level in the Geography hierarchy. If the value of the group System Geography field is \Geography, members of the group have access to records with blank System Geography fields. If the value of the group System Geography field is not blank and not

\Geography, and the record's System Geography field is blank, members of the group have access to records in queries but do not have access to records in forms.

If you do not intend to use groups to restrict access to or visibility of records, and records have values in their System Geography fields, then set the value of the group System Geography field to \Geography.

This is discussed in greater detail in "Organization and geography".

Members tab

The Members tab is used to control which users and other groups are members of a group.

You can add users directly to the group by clicking the Add Users action.

You can add users to a group indirectly by clicking the Add Groups action.

Adding a group as a member of another group causes all user IDs and groups that are members of the added group to be members of the group to which they were added. It also gives the Access Permissions in the added group to the group.

Access tab

The Access tab determines how much access membership in the group grants to records created from specified forms. It also determines what actions the members of the group are allowed to perform on the records. In addition, the Access tab determines the access the members of the group have to the tabs and sections of the form. The Access tab also determines the access to models and their associated actions.

The appearance of the Access tab varies with the type of object for which security is being defined. The Access tab has an Object panel and a Permission panel.

The Object panel shows a tree that contains a list of forms, organized by module.

The tree also contains all of the tools that the IBM TRIRIGA Application Platform

446

© Copyright IBM Corp. 2011, 2015

provides, such as the Data Modeler and the Report Manager. The tree also contains a list of all the models available in the environment.

The content of the Permission panel varies based on what is selected in the Object panel.

Modules that contain published forms are represented by a plus sign icon. You can see the forms under a module by clicking the module's plus sign icon. Tools and modules that do not contain any published forms are represented by a dot.

Models appear in the Object panel under the Models node. Only systems with models have the Models node.

You can select a module, tool, or anything else that is in the Object panel by clicking its name. When something is selected in the Object panel, relevant choices for permissions appear in the Permission panel.

The permissions vary with the type of object that is selected in the Object panel.

The meaning of the permission also varies with the type of object that is selected.

Tip:

Review the access permissions in any group that you create. A new custom group by default provides no access to any tool or form object. With a new group, all access is prohibited until you explicitly grant it. Users in an unmodified, newly created group do not have access to anything.

Module access

When a module is selected in the Object panel, two kinds of permissions are shown in the Permission panel: Data Access permissions and Application Access permissions. Data Access uses CRUD credentials to govern how users can access the record as a whole. Application Access governs what users can do to a record and the actions that can be performed on a record.

You may select one Data Access permission. Initially, No Access is selected. No

Access means just what it sounds like. The other levels of data access permissions allow progressively more access to records, all the way up to Read, Update, Create, and Delete, which allows members of the group to look at existing records, change the contents of records, create new records, and delete records.

The forms listed in a group are organized by module. The data access permission that you select for a module is used as the default data access permission for the forms in the module. If you do not select a data access permission for a form, then the form inherits its permissions from the module.

The Application Access permissions govern which actions can be performed on a record. Each permission corresponds to an action in a state transition family. If you select the check box next to an action permission at the module level, members of the group can perform that action using any form in the module.

Tool access

When a tool is selected in the Object panel, the members of the group can either have full access to a tool or no access. Tools include the Data Modeler and

Workflow Builder. The Report Manager has more permission choices.

Chapter 13. Security

447

Form access

When you click the plus sign icon to the left of a module name, it shows the forms in the module.

When a form is selected in the Object panel, the Permission panel contains Data

Access, Application Access, and Form Action Access permissions.

You may select one Data Access permission. Initially, Inherit from Parent is selected.

The Inherit from Parent access permission sets the access level of the form, tabs, or sections. In a situation where the user is a member of multiple security groups,

Inherit from Parent means that this group inherits permissions from its group parent, not from the collection of multiple groups.

No Access means just what it sounds like. The other levels of data access permissions allow progressively more access to records, all the way to Read,

Update, Create, and Delete, which allows members of the group to look at existing records, change the contents of records, create new records, and delete records.

The Application Access permissions shown for a form only include actions from the state transitions that the form uses. Members of the group can perform an action on a form's record only if the action's check box is selected in the list for the form or its module.

The Form Action Access permissions shown for a form include all actions added in the form to sections as well as any action fields. Members of the group can perform a form action on a form's record only if the action's check box is selected in the list for the form and if they have Read, Update, Create, and Delete access to the form.

Tabs and sections access

When you click the plus sign icon next to the name of a form, you see the tabs that the form contains. If a tab contains sections, it has by a plus sign icon you can click to see the sections.

You can select one of the Data Access permissions. Initially, Inherit from Parent is selected. If the members of a group have No Access to a tab or a section, they cannot see the tab or section.

Model access

You can open the Models tree to assign models to a security group, and assign permissions to a model.

When a model is selected in the Object panel, the Permission panel contains the following Model Access permissions: No Access; Read; Read and Update; Read,

Update, and Create; and Read, Update, Create, and Delete. You can select one

Model Access permission.

No Access means just what it sounds like. The other levels of data access permissions allow progressively more access to models, all the way to Read, Update,

Create, and Delete, which allows members of the group to look at existing models, change the contents of models, create new models, and delete models.

448

© Copyright IBM Corp. 2011, 2015

In addition, the actions that are available through the model are shown. The Model

Action Access permissions shown for a model include all actions added in the model to sections as well as any action fields. Members of the group can perform an action only if the action's check box is selected and the members have the appropriate access to the model.

Model security data is cached for better performance at runtime. The cache is automatically refreshed when security assignment changes are made in Security

Manager. If needed, you can manually refresh the cache in the Administrator

Console. Select the Cache Manager, then in the Flush a Cache section, select either

Security Scope

or All Caches.

Admin group

The Admin Group is a very special group for the IBM TRIRIGA Application

Platform. When they have license access, members of the Admin Group are automatically allowed access to all records, models, and to most of the tools in the platform environment whether they have been granted explicit permission to do so or not.

The only tool access that membership in the Admin Group does not confer to its members is the tool access that is granted to user IDs that have an IBM TRIRIGA

Application Builder license.

To ensure the security of records in the IBM TRIRIGA Application Platform environment, it is very important to limit the users that are members of the Admin

Group to a small number of trusted users.

Do not delete or copy the Admin Group.

Organization and geography

You can restrict user access to records based on the relationship between individual records and Organization and Geography. The definition of a group in the Security

Manager includes the System Organization and System Geography fields in the

Data Access section of the General tab.

Most business objects have a field that is named OrgName and a field that is named Geography Name. These fields are in the business object's General section.

These fields are automatically supplied by the IBM TRIRIGA Application Platform.

Because the platform automatically adds these fields, they do not appear in the

Data Modeler. They do appear in the Form Wizard as part of the layout.

The OrgName field can have as its value any Organization record. The

GeographyName field can have as its value any Geography record. The Geography hierarchy and the Organization hierarchy can be accessed in the Portfolio menu.

A new record inherits the System Organization and System Geography values of the currently logged in user as default values. For example, if Sam is logged in and has the values ZetaBank and US for these fields in his My Profile record, then most new records he creates have these values by default.

By default, many dependent child records inherit their System Organization and

System Geography values from their parent records. For example, a new clause in a real estate contract inherits from the parent contract.

Chapter 13. Security

449

If a record's System Organization field has a value, the value of the field may restrict the users that can access the record. Users can access a record if they are a member of at least one security group that contains a System Organization value that is the same as or higher in the hierarchy than the organization contained in the record's System Organization field.

If a record's System Geography field has a value, the value of the field may restrict the users that can access the record. Users can access a record if they are a member of at least one security group that contains a System Geography value that is the same as or higher in the hierarchy than the geography contained in the record's

System Geography field.

Attention: The logged in user's System Organization and System Geography values do not control any access rights. It is the security groups that the user is a member of that control access rights.

It is possible for a record to not have a value for the System Organization or

System Geography fields. If a record's System Organization field has no value, the record is treated as though the value is \Organizations. If a record's System

Geography field has no value, the record is treated as though the value is

\Geography.

The following table summarizes the relationship between a record's System

Organization field and a group's System Organization field.

Table 30. Relationship between a record's System Organization field and a group's System

Organization field

Record Record Record

Group

System Organization is blank

User in group DOES see record in queries and forms

System Organization is blank

Group

System Organization is \Organizations

Group

User in group DOES see record in queries and forms

System Organization is not blank

User in group DOES see record in queries, but does NOT see record in forms

Note:

In UX apps, records shown to users are records in queries

System Organization is \Organizations

User in group DOES

NOT see record in queries or forms

User in group DOES see record in queries and forms

User in group DOES

NOT see record in queries or forms

System Organization is NOT blank

User in group DOES

NOT see record in queries or forms

User in group DOES see record in queries and forms

User in group DOES see record in queries and forms if the value in the group

System Organization is at the same hierarchy level as or at a higher level than the value in the record System

Organization

The following table summarizes the relationship between a record's System

Geography field and a group's System Geography field.

450

© Copyright IBM Corp. 2011, 2015

Table 31. Relationship between a record's System Geography field and a group's System

Geography field

Record Record Record

Group

System Geography is blank

Group

System Geography is blank

User in group DOES see record in queries and forms

System Geography is \Geography

User in group DOES

NOT see record in queries or forms

System Geography is NOT blank

User in group DOES

NOT see record in queries or forms

User in group DOES see record in queries and forms

User in group DOES see record in queries and forms

User in group DOES see record in queries and forms

System Geography is \Geography

Group

System Geography is not blank

User in group DOES see record in queries, but does NOT see record in forms

Note:

In UX apps, records shown to users are records in queries

User in group DOES

NOT see record in queries or forms

User in group DOES see record in queries and forms if the value in the group

System Geography is at the same hierarchy level as or at a higher level than the value in the record System

Geography

After you add, update, or delete a System Organization or a System Geography, clear the Security Scope cache in the Administrator Console. For more information about the Administrator Console, see the IBM TRIRIGA Application Platform 3

Administrator Console User Guide.

Group best practice

Your group structure can be difficult to manage if your groups combine System

Organization, System Geography, and application security in the same group. The best practice is to use multiple groups and layer groups for each user.

For example, Group 1 defines System Organization security as

\Organizations\Greenpoint. Group 2 defines System Geography security as

\Geography\North America\United States. Group 3 defines a level of application security as Read access to triBudget. You assign a user to Group 1, Group 2, and

Group 3, and the user has the combined security of all groups.

Forms, reports, and queries

The ENFORCE_GUI_LEVEL_QUERY_SECURITY property in the

TRIRIGAWEB.properties file controls form-level security in reports and queries.

When this property is N, the default, queries and reports do not consider form-level security.

When this property is Y, the user's group controls whether the user can access records in reports and queries. If a user does not have access to records being queried, no results are returned. If at least one of a user's groups has at least read access, the data is returned to the form. For module queries, only data for the forms in the module to which the user has access are returned.

Chapter 13. Security

451

Projects

One of the business objects that is standard with the IBM TRIRIGA Application

Platform is triCapitalProject in the triProject module. triCapitalProject records are used to track a set of related activities and their associated financial data. The triCapitalProject business object is useful for applications that manage projects.

triCapitalProject records have a security-related purpose that is independent of project management. triCapitalProject records can be used to restrict who can access records. They can be used to filter which records are visible to the user.

Access to records associated with a triCapitalProject record is limited to a specified set of users. You can allow some users to view but not change records that are associated with a Capital Project record.

Company projects and active projects

The IBM TRIRIGA Application Platform comes with one standard triCapitalProject record that has the name Company Level. There are a few things about the

Company Level project that make it special.

v You may not edit or delete the Company Level project.

v Users are not denied access to a record because the record is associated with the

Company Level project.

v A user must have at least one projects license to change their active triCapitalProject.

When a user signs on to the IBM TRIRIGA Application Platform, the user's session with the platform is associated with a triCapitalProject record. This triCapitalProject record is referred to as the active project. The name of the active project is shown above the menu bar.

When a user clicks the Find Project icon, if the user has permission to change the active project to a triCapitalProject record other than Company Level, a list of other triCapitalProject records pops up. The current project can be changed to one of those capital project records. To change the appearance of the list of capital projects that is popped up, update the query named Portal Project Search in the Report

Manager.

Clicking the Company button sets the current project to the Company Level project.

When a user signs out, the system saves their active project. The next time that user signs in, the user starts in that project.

When projects are displayed in a grid in the user's portal, the user can change the active project by clicking the project switching icon to the left of the project name.

The project switching icon is only available when the record corresponds to a capital project record and the user is granted project security privileges.

When the user clicks the project switching icon for a record in a non-default project, the user's active project is switched to that record's project. When the user clicks the project switching icon for a record in a default project, the user's active

452

© Copyright IBM Corp. 2011, 2015

project is switched to the Company Level, if not already there. If a user's project is changed, the current project name at the top of the home portal is updated and the portal is refreshed.

The active project is significant in two ways.

v Every record has an internal association with a triCapitalProject record. When a user interactively creates a record, it is internally associated with a triCapitalProject record. When a workflow creates a record, the workflow can either explicitly specify a triCapitalProject record for the new record or use the triCapitalProject record that is active for the current user.

v The data that is returned by reports and queries can be limited to the active project. To restrict the data that is returned by reports and queries to only projects to which a user has security access, set the USE_PROJECT_SECURITY property in the TRIRIGAWEB.properties file to Y. For information about the properties files, see the IBM TRIRIGA Application Platform 3 Installation and

Implementation Guide.

When a user creates a new record, the Capital Project that is associated with that record depends on the following factors: v The project for a top-level record is the user's current active project.

v If the record is a new child record and the Project Containment Disabled property in the association definition for the dependent business object is off

(the default), the record's project is that of its parent record. If the Project

Containment Disabled property is on (selected), the record's project is the user's current active project.

v

The project for an existing record that is made to be the child of another record is the project of that other record.

A record is considered to be a child if one of the following is true: v It is associated to a record via a dependent association.

v It is a hierarchical child through a platform hierarchy. An exception is the child of root, which is treated as a new record.

v It is a record in a dependent section.

When requests come to the server, the user's active project is relevant because the active project drives among other things what the project context is when synchronous workflows run. To have the user's current active project always be the active project no matter what, set the RECORD_PROJECT_CONTAINMENT property in the TRIRIGAWEB.properties file to N. For information about the properties files, see the IBM TRIRIGA Application Platform 3 Installation and

Implementation Guide.

When using projects, be aware that when a user has access to multiple projects, that user may create records that should be part of one project while in a different project. This can result in the wrong users having access to the records, or in users who need access being denied it.

Project security setup

triCapitalProject records are managed using the Capital Projects page. To access the

Capital Projects page, go to Projects > Capital.

Chapter 13. Security

453

To create a new capital project, click New Project. To edit a capital project record, click the hyperlinked name. To delete a capital project record, select the check box next to it and click Delete Project.

When you are creating a capital project record only for security purposes, the only field in the General tab that you need to complete is the Name field.

All of the security-related fields in the capital project form are in the Security tab, which is divided into sections that control access to records associated with the capital project record.

Users that are members of groups listed in the Group Access section have access to records internally associated with the capital project record. If a user ID's only access is as a member of groups that have their Read Only check box selected, the user can view but not change records that are internally associated with the capital project. Use the Find action to add a group to the Group Access section.

User IDs can also have access to a record internally associated with a capital project record if they are listed in the User Access section. If a user ID's Read Only check box in the User Access section is selected and the user does not belong to any groups listed in the Group Access section that do not have their Read Only check box selected, the user can view but not change records that are internally associated with that capital project record. Use the Find action to add a user to the

User Access section.

For this security to be enforced, you must click the Activate action on the capital project form. Depending on the approval requirements for capital projects, the project may need to be approved. After the project is in Active status, the security is enforced. For more information about creating approval processes, see the IBM

TRIRIGA 10 Application Administration User Guide.

Workflows and projects

When a synchronous or subflow workflow starts, its active project is always the current project. If initiated by a user, the current project is the active project of the user who initiated the workflow. If the workflow was launched from a Call

Workflow task, the initial project is the project context at the time the Call

Workflow task ran. Note that asynchronous workflows run with a setting of `no project'.

The active project does not affect the ability of a workflow to access records, because workflows can access all records without being affected by project-related restrictions. However, Query tasks can filter results based on the active project. See

"Set Project Task" for details.

Initially, new records are not assigned to any project. When a workflow task creates a new record, you can specify that the new record should be associated with a triCapitalProject record in the following ways: v A workflow task can set the project on a record to a specified project. The specified project can be either the Company Level or provided by the project of another record.

v A workflow task can specify that a new record can be associated with the same triCapitalProject record as another record.

v A workflow task can specify that a new record can be associated with a triCapitalProject found through a Query task or another task.

454

© Copyright IBM Corp. 2011, 2015

Reports

Use a Set Project task to change the workflow's current project context or to change a record's project.

There are three types of reports: System Reports, Community Reports, and My

Reports. You control access to each report type in the Access tab of each group.

Select Report Manager in the Object panel. These permissions control access to the tabs in the Report Manager.

If a group has No Access to system reports, users in that group do not see the

System Reports tab in the Report Manager. If a group has Full Access to system reports, users in that group can manage (create, edit, copy, delete) and share any system report.

Attention: Be careful to which groups you give system report Full Access because users with such access can potentially break the application with this access level.

If a group has No Access to community reports, users in that group do not see the

Community tab in the Report Manager. If a group has View Access to community reports, users in that group can run community reports and copy those reports into their own My Reports tab. Note that community reports are system reports that have been determined to be useful for end users to be able to copy and modify for their own use as My Reports. To manage a community report, a user must belong to a group with access to system reports.

If a group has No Access to My Reports, users in that group do not see the My

Reports tab in the Report Manager, and users in that group cannot create or manage their own personal reports. If a group has Manage permission to My

Reports, users in that group can create, edit, copy, and delete their own personal reports. If a group has Manage and Share permission to My Reports, users in that group also can share their reports with other groups.

The Copy as Community Report action, on the My Reports tab in the Report

Manager, is available only to users belonging to a group with Full Access to system reports. The Share Report action is only available to users belonging to a group with Manage and Share permission for My Reports.

In addition to controlling the access to the tabs in the Report Manager through the

Security Manager, you also can specify an additional granularity of security for individual reports, based on the type of report, through the Security sub-tab in the report's definition.

For system reports, there is no Security tab. Groups either have full access or no access to system reports.

For community reports, the Security tab in the General tab can be used to restrict view access to a community report to the specified groups. If the Security tab is empty, the community report is available to all groups that have access to the

Community tab.

My Reports also has a Security tab. If a user belongs to a group with Manage and

Share permission for My Reports, that user can share personal reports with members of other groups. By default, shared groups have View Access, i.e., they can run the report. However, the owner of the report also can specify more

Chapter 13. Security

455

granular levels of access to shared reports. If the user chooses, the user can give one of the groups All access, which effectively grants that group the same privileges as the user has as the owner. The owner of a My Report always has view, edit, delete, and copy access to that report.

The Report Manager Administration tab displays only for members of the Admin

Group. The Administration tab lists all My Reports for all users. In this tab, an administrator can change the owner of a report, or copy, delete, or share My

Reports. In addition, an administrator can open individual My Reports and update the Security sub-tab as needed.

For information about the Report Manager, see the IBM TRIRIGA Application

Platform 3 Reporting User Guide.

Audit trails

Some records may be considered so sensitive that you want to keep a record of all changes made to them. A record of all changes that were made to a record is called an audit trail.

These are the most common reasons for wanting an audit trail.

v Users with legitimate access to records may be tempted to do something dishonest. This often happens when the records in question are used to represent money or other things that are worth money.

v There is an undesirable legal consequence if an improper change to, or action on, a record is performed.

v

There is a regulation or standard that requires your company to track changes to records.

If any of these concerns is relevant to a record, it is important to have an audit trail that tells who did what to each such record and when they did it. Having an audit trail is a disincentive for dishonesty, because it makes it easier to discover dishonest actions. An audit trail removes speculation about what actually happened.

An audit trail is an historical record of everything that happened to a record.

Because it is an historical record, the information that is in an audit trail cannot be altered or deleted.

There are two main reasons for not wanting an audit trail: v Maintaining an audit trail increases the amount of time that an operation takes.

Saving the audit records takes additional time.

v Maintaining an audit trail can greatly increase the amount of storage that an application uses. In addition to needing space to store records, you need space to store the audit trail. The space that is needed to store the history of everything that ever happened to a record can be significantly larger than the record itself.

Support for audit trails is built directly into the IBM TRIRIGA Application

Platform. Though it is possible to implement audit trails as part of an application's business logic, IBM TRIRIGA strongly suggests that you use the audit trail support that is built into the platform. There are at least three reasons for this: v An audit trail that is maintained by the platform is more secure than an audit trail maintained by the application. An audit trail based on an application's

456

© Copyright IBM Corp. 2011, 2015

business logic is only as reliable as the application itself. If there are bugs or mistakes in the application, an audit trail that is maintained by the application may not be accurate. The accuracy of an audit trail that is maintained by the built-in audit trail mechanism is unaffected by bugs or mistakes in an application.

v It takes a lot more work to build the logic for an audit trail into an application than it does to use the audit trail support that is built into the platform.

v Although all audit trail mechanisms increase the amount of time it takes an application to do things, an audit trail that is maintained by the platform's built-in mechanisms has less impact on performance than an audit trail that is maintained by an application.

You set the options for maintaining an audit trail for records that are created from a business object by setting the relevant properties of the business object with the

Data Modeler.

The following properties of a business object control the generation of an audit trail for records that are created from the business object.

Audit Actions

If the Audit Actions check box is selected, when a user clicks a sub action in a form that is editing a record that is created from this business object, an audit record is created.

Selecting the Audit Actions check box enables the creation of audit records that identify the sub action that was performed, the user ID of the user that clicked the sub action, and when the sub action was clicked. Selecting the Audit Actions check box only enables the generation of audit records for sub actions that you specify should be audited by selecting their Log check box. For audit records to be generated for a particular sub action, the

Log check box in the sub action's properties must be selected.

Select the Audit Actions check box for the Request for Information (RFI) metrics and for reports in IBM TRIRIGA Workplace Performance

Management products.

Audit Access

If the Audit Access check box is checked, every time a user utilizes a form to view the contents of a record that is created from this business object, an audit record is created.

Audit Interactive Data

If the Audit Interactive Data radio button is selected, every time a user uses a form to change the contents of a record that is created from this business object, an audit record is made. The audit record contains the user

ID that made the change and the time of the change. The audit record also contains the old value and new value of every changed field.

Audit All Data

If the Audit All Data radio button is selected, an audit record is made for every change to a record created from this business object. This includes changes that are made by a user in a form, due to a formula calculation or rollup calculation, or by a workflow. This does not include changes that are made if the record is modified by an editable query.

Selecting the Audit All Data property can affect performance.

Require Explanation

Chapter 13. Security

457

If the Require Explanation check box is selected, when a user uses a form to change the contents of a record that is created from this business object, the user is asked to enter a reason. If the Require Explanation check box is selected, the Audit Interactive Data property is automatically selected.

The reason that is given for the changes to the record is included in the audit record along with the other information about the change.

Whether you are creating a new sub action or editing it, after you click the appropriate action you check the Log check box to enable auditing of the sub action.

Configuring the generation of audit records is only half of the IBM TRIRIGA

Application Platform's built-in mechanism for maintaining an audit trail. The other half is a mechanism for viewing audit records.

If a form is used to edit records for which audit records are generated for data access or changes, you need to update that form to show the Audit tab. To do so, revise the properties of the form for the business object where you would like to see the audit data and check Show Audit Actions.

After the form is published, the form has a tab that is labeled Audit. The purpose of the Audit tab is to display all the audit records that contain data changes that were made to the record.

Three columns display in an Audit tab.

Modified By

The user ID that made the changes.

Comment

The reason the user entered if required to enter a reason for making changes to a record through a form.

Modified On

When the data was changed.

Tip:

You may not want all users to see the information in the Audit tab or the

Audit Actions tab. Access to those tabs is controlled through group permissions, just like any other tab.

To see details of the data changes that were made, click the hyperlinked audit record. The Audit Details form shows the user that made the change, the name of the field that was changed, the value of the field before it was changed, and the value of the field after it was changed. If changes were made while the record was created, the fields had no previous value, and the old value is blank.

If a form is used to edit records for which audit records are generated as a result of clicking sub actions, the form has an Audit Actions tab. The purpose of the

Audit Actions tab is to display the audit records generated to record actions that were performed on the record.

The Audit Actions tab shows every recorded sub action that was clicked in the record. The Audit Actions tab shows the label of the sub action, the user that clicked the sub action, and when the sub action was clicked. To allow a user to view this data, you need to update that form to show the Audit Actions tab. To do so, revise the properties of the form for the business object where you would like to see the Audit data and check Show Audit Actions.

458

© Copyright IBM Corp. 2011, 2015

Workflow instances

Depending on your auditing requirements, it may be good enough to know what sub actions were clicked for records, when those sub actions were clicked, and who clicked them. If you need to know what workflows were started as a result of the sub actions and what the workflows did to records, you need more information than is in the Audit Actions tab.

The IBM TRIRIGA Application Platform provides a way for you to examine the actual workflows that ran in response to clicking sub actions and to see how the workflows ran. This feature is based on the fact that workflows run only in response to an action or system event happening to a record. You can see the workflows that ran in response to something happening to specific records.

To be able to see workflows that were started for a record, you need to: v Decide which workflows are of interest.

v Specify that information about each running of those workflows should be saved.

v Include a tab in appropriate forms for viewing the records of the workflows that have run.

In order for information to be saved each time that a workflow is run, the Save

Workflow Instances check box in the workflow's properties must be selected. The

Save Workflow Instances check box is discussed in "Start Task".

If a workflow's Save Workflow Instances check box is selected, every time the workflow runs, a copy of the workflow is kept with information about how it ran.

This saved information about a single running of a workflow is called a workflow instance.

You can view all saved workflow instances for a workflow by using the Workflow

Builder. To do this, select the workflow of interest and then click the List All

Instances action.

For researching what a workflow did when it was run a particular time for a particular record, you include a Work Flow Instance tab in the forms that are used to access the type of records that are of interest. To configure a form to include a

Work Flow Instance tab, edit the form's properties so that its Show Workflow

Instance check box is selected. The Show Workflow Instance check box is discussed in "Form Properties".

The Work Flow Instance tab shows the name of each workflow that ran, the current status of the workflow, and when the workflow started. There is no indication of what started the workflow. You need to use the times sub actions were clicked and the times that workflows were started to match them up.

The statuses showing in the Work Flow Instance tab are as follows:

For synchronous workflows: v Active (the workflow is currently running) v

Completed (the workflow has completed)

For asynchronous workflows:

Chapter 13. Security

459

v Aborted, Aborted-Warn (the workflow was aborted using the Stop capability in the Administrator Console) v

Active (the workflow is currently running) v Completed, Completed-Warn (the workflow has completed) v Failed (the workflow encountered an error and could not continue; information about the problem was written to the System Log) v Skipped (the workflow would have run, but the Start Conditions were not satisfied) v Stopped, Stopped-Warn (the workflow ran a Stop task) v Waiting, Waiting-Warn (the workflow is waiting for a user (user action or approval task))

If Warn is on the status it means that a problem was encountered, information was written to the System Log, and the workflow continued processing.

The workflow names in the Work Flow Instance tab are hyperlinks. If you click a workflow name, the workflow editor shows the actual workflow that ran. Even if the workflow changed after this run, you see the actual version of the workflow that ran.

The workflow editor displays the workflow differently from when you access it through the Workflow Builder. Workflow tasks that were performed are highlighted with a green dashed border. Looking at the highlighting, you can see the path that was taken through the workflow when it ran.

Tip:

The workflow trace that you see in the Work Flow Instance tab can be useful in debugging a workflow, since dashed green highlighting shows the path that the workflow followed.

If a workflow step was started but has not finished, it is highlighted with a red dashed border.

Workflow instances subject to cleanup agent

The IBM TRIRIGA Application Platform does not keep workflow instances indefinitely. The Cleanup Agent discards workflow instances after a specified number of days. The number of days that the platform keeps workflow instances is determined by the platform's configuration properties.

The IBM TRIRIGA Application Platform configuration properties are discussed in the IBM TRIRIGA Application Platform 3 Installation and Implementation Guide.

Audit trail integrity

By auditing the actions that users perform on a record and the changes that users make to its data, it is possible to have a detailed and accurate audit trail with which you can determine exactly how the record came to have its current data and state.

There are some rules that you must observe to ensure the integrity of audit trails that are produced by the IBM TRIRIGA Application Platform:

Make changes to an application only when users are not using it.

460

© Copyright IBM Corp. 2011, 2015

It is a good idea to keep users from using an application while it is being changed, just to be sure of getting consistent results. Another reason to keep users from using an application while it is being changed has to do with accurately interpreting audit trails.

It is important to know whether the consequences of clicking a sub action happened before or after a change to the way an application works. If users are using an application at the same time it is being changed, it may become difficult to know if an action and its consequences happened before or after a change. If the change affected which workflows are started by the action, it may not be possible to know which workflows were started by an action.

Restrict access to the Data Modeler.

Even if you are only auditing data changes, it is still important to restrict access to the Data Modeler.

Through the Data Modeler, it is possible to turn off generation of audit records for all records that are created from a business object and then later turn the generation of audit records back on. While the generation of audit records is turned off, a user can change data in records without the change being recorded in an audit trail. Also, there is no record in the audit trail that generation of audit records was turned off or on.

Security settings should prevent users from deleting records for which you are keeping an audit trail.

When a record is deleted, the audit records associated with the record are also deleted.

Instead of designing audited records to be deleted, design them to have a retired state that keeps them from being seen or used in most contexts.

Avoid designing records that are likely to accumulate many audit records.

There is no way for workflows to access audit records. They must be interpreted manually. If a record accumulates a large number of audit records, it may not be practical to interpret the audit trail.

To avoid this problem, try to design records so that they do not accumulate a large number of audit records.

Changes to records that have an audit trail should only be initiated from a form.

Data audit records are only created by changes that are made to a record through a form.

Audit records are not created when records are created or modified by the

Data Integrator or by other means.

If you cannot follow these rules, and you must have a secure audit trail, you can use your database manager to keep an audit trail. The platform creates a database table for each business object. Records that are created from a business object are stored in the database table that corresponds to the business object used to create the record. The details of auditing database tables vary with the database software used. Consult your database administrator or database documentation for the specifics.

Chapter 13. Security

461

Queries control visible records

Queries with filtering can be used to control the records that are visible in navigation items, query sections, and through Find and Add actions. You can craft queries so that users only see the records that you want them to see.

Limiting user access to records this way has one important advantage. It gives you a great deal of flexibility in how you filter a user's view of records. However, it has enough drawbacks that you should only use this technique as a last resort. Here are some of the problems with this technique: v Because multiple queries must be made consistent to present a consistent view of the data, errors are more likely when you use this security technique than with other security techniques.

v

Because the policy that controls the records that a user is allowed to see may be replicated in multiple queries, this technique makes it difficult to keep the policy consistent when you change it.

Workflows bypass security

Workflows are not subject to any security restrictions. If you want filtering that is based on organization or geography, you must explicitly specify those restrictions in the workflow or in queries that the workflow uses.

462

© Copyright IBM Corp. 2011, 2015