Secure Your Kintana System

NEW! Deploy Metrics v1.3

ZDS

Kintana Standards

By: Dave Goodall I'm going to describe how to secure a HP PPM (Project and Portfolio Management) system runnng the Demand and Deliver Modules. This is by far the most common configuration. The security model is easily extensible if you're also using Portfolio or Financial or one of the other management modules. Tip : Print this page in landscape mode for best results.

The first thing to do is to define the types of user that access the system. I suggest these types based on the level of access they need:

The next step is to list all the access grants in the system.
The sql on this page will get that information for you.

Now start up a spreadsheet and assign the grants to each user type. Each level inherits the rights of the level below and adds new rights.

There's an exception in that we don't want the the Standard and Power users to have all the read rights we're granting the auditors.

For detail on what a particular grant does, check Appendix A of the Security Model and Reference manual.

Your rights set will be different depending on what you have installed, but the result should look something like this:

Module          Access Grant                          Read Only  Standard  Power  Admin  Audit

Demand Mgmt     View Requests                                 x         x      x      x     x

Demand Mgmt     Edit Requests                                           x      x      x
Sys Admin       Open Workbench                                                 x      x
Change Mgmt     Edit Packages                                                  x      x
Sys Admin       Submit Reports                                                 x      x

Config          View Activities                                                       x     x
Demand Mgmt     View All Contacts in Request                                          x     x
Demand Mgmt     View Contacts                                                         x     x
Change Mgmt     View Environment Refreshes                                            x     x
Environments    View Environments                                                     x     x
Config          View Notification Templates                                           x     x
Change Mgmt     View Object Types                                                     x     x
Change Mgmt     View Packages                                                         x     x
Sys Admin       View Portlet Definition                                               x     x
Change Mgmt     View Releases                                                         x     x
Config          View Report Types                                                     x     x
Demand Mgmt     View Request Header Types                                             x     x
Demand Mgmt     View Request Types                                                    x     x
Sys Admin       View Security Groups                                                  x     x
Sys Admin       View Server Tools                                                     x     x
Config          View Special Commands                                                 x     x
Config          View User Data                                                        x     x
Sys Admin       View Users                                                            x     x
Config          View Validations                                                      x     x
Config          View Workflows                                                        x     x

Sys Admin       Configure Modules                                                     x
Sys Admin       Distribute Modules                                                    x
Config          Edit Activities                                                       x
Config          Edit Contacts                                                         x
Sys Admin       Edit Dependent References                                             x
Environments    Edit Environments                                                     x
Config          Edit Notification Templates                                           x
Change Mgmt     Edit Object types                                                     x
Sys Admin       Edit Portlet Definition                                               x
Change Mgmt     Edit Releases                                                         x
Config          Edit Report Types                                                     x
Demand Mgmt     Edit Request Header Types                                             x
Demand Mgmt     Edit Request Types                                                    x
Sys Admin       Edit Security Groups                                                  x
Config          Edit Special Commands                                                 x
Config          Edit User Data                                                        x
Sys Admin       Edit Users                                                            x
Config          Edit Validation Values                                                x
Config          Edit Validations                                                      x
Config          Edit Workflows                                                        x
Demand Mgmt     Manage Contacts                                                       x
Demand Mgmt     Manage Demands                                                        x
Change Mgmt     Manage Packages                                                       x
Change Mgmt     Manage Releases                                                       x
Sys Admin       Manage Reports                                                        x
Demand Mgmt     Manage Requests                                                       x
Sys Admin       Migrate Kintana Objects                                               x
Change Mgmt     Override Change Mgmt Participant Restriction                          x
Demand Mgmt     Override Demand Mgmt Participant Restriction                          x
Sys Admin       Override Key Fields Segmentation                                      x
Sys Admin       Ownership Override                                                    x
Sys Admin       Server Administrator                                                  x
Sys Admin       Server Tools: Excute Admin Tools                                      x
Sys Admin       Server Tools: Execute SQL Runner                                      x
Change Mgmt     Submit Environment Refreshes                                          x
Sys Admin       Synchronize Meta Layer                                                x

There's room to carve out other user types ( eg.: a 'Super User' type if you wanted to assign some of the 'Manage' rights to very expert users), but keep it simple - the fewer the better.

With the user types and their access grants worked out the next step is simple.

Set up security groups for each user type. I suggest these security group names and descriptions:

Security Group           Description

ACCESS Read Only         Able to view requests.
ACCESS Standard          Able to create, edit, approve requests.
ACCESS Power             Able to process packages and requests.
ACCESS Administrator     Full system rights.
ACCESS Audit             Able to view everything.

Set up template users for each user type with the access rights set you just worked out:

User Name                First Name    Last Name

TEMPLATE Read Only       First         Last
TEMPLATE Standard        First         Last
TEMPLATE Power           First         Last
TEMPLATE Administrator   First         Last
TEMPLATE Audit           First         Last

Set the Read Only and Standard templates up with Demand Licenses. Power users get Demand and Deliver licenses.

In this model the license(s) a user has are a solely a consequence of the access rights he is being given

From now on, to create a new user record, copy the template with the correct access grants and customize the name, email and so on

Go through all the enabled users. The security groups they have will be of two types : groups that give users access grants, and groups that allow users to approve a Demand or Deliver workflow step.

Delete the access grant security groups, and replace them with just ONE of the new ACCESS security groups.
If you want to bump up a user's access rights later then delete the ACCESS security group and insert the next higher one. Change the license too if necessary.

Leave the workflow step security groups in place!

Disabled user records should NOT have security groups of either kind in place. Period.

Remove ALL security groups from disabled user records.
The sql on this page will locate these user records for you.

While you're at it I also suggest clearing the email address. This isn't essential, but makes for a clear visual separation of enabled-disabled users in the User workbench.

These security groups are specified on the 'Security Tab' of workflow steps, and permit the users in them to approve a step.

Prefix the names of these groups with 'WSS: ' (Workflow Step Security) to make it visually very clear what the group is used for.

If you have sql validations that reference security groups by name, you will need to update them. The sql on this page will locate these validations for you.

Use the 'WSS:' security group's description field to identify the workflow(s) the group is used on.

You will very likely find 'WSS' security groups with linked access grants. Remove ALL linked access grants from 'WSS:' security groups! WSS groups must ONLY be used to give the users in them rights to approve a step. It is critically important that users do not acquire access grants accidentally because of rights that happen to exist on this tab! Access rights are ONLY granted by membership in one of the ACCESS security groups!

NO step in ANY workflow may have a Security tab that has explicit user names! Workflow step security tabs should ONLY use Security Type 'Security Group Name' and have only 'WSS:' security group names! The sql on this page will locate these workflow steps for you.

If the 'WSS:' security group is not used by a Deliver workflow (ie the 'Security Group Used By' 'Packages' checkbox is not checked ) then the 'Allowed Change Management Workflows' list should be empty! If it isn't, then clean it out.

Deliver (package) workflows should have no entries listed in 'Allowed Request Types'. and the 'Always restrict new Request Types' checkbox MUST be checked!

In this base security model we're going to start out open and allow all the request types listed on a Workflow's 'Request Types' tab to be available to all the ACCESS user types:

Remove the current security groups and replace them with the ACCESS security groups:

Set the access grant checkboxes to match each access level. I suggest that even for the Administrator type that 'Delete' is not enabled. As a policy to maintain a complete audit trail I suggest that requests are never deleted.

When you retire and disable a request type remember to clear the 'Create' flags for all the ACCESS security groups. Users will still be able to work with old requests in the system, they just won't be able to create any more of them.

We're almost done...

Open the Security Tab on each enabled Report Type and set the 'Reports can be submitted and viewed by' selection to 'Only users in the allowed Security Groups'

Remove any pre-existing entries from the 'Allowed Security Groups' list

Add the ACCESS Audit, ACCESS Administrator, and ACCESS Power security groups to the 'Allowed Security Groups'. Whether you want to add the ACCESS Standard or ACCESS Read Only security groups depends on whether you want to vary from the model by giving 'Submit Report' rights to these security groups.

Make sure that the 'Always restrict new Security Groups' checkbox is checked

and, that's it, apart from one oddity that you'll need to bear in mind:

If you look at the 'Used By' tab of a security group, you will typically see 'Step Security' security groups (permitting step approval on various workflows), and 'Demand Security' security groups (permitting access to various requests).

These entries act in the positive sense : if they exist then you are allowing access to the members of those security groups.

You will also see any number of 'Report Security' entries.

These do NOT indicate security groups that permit access to the specified report!

If you take one report type at random, and then open that Report Type's 'Ownership' tab, you will see security groups listed in two panes: 'Restricted Security Groups' on the left, and 'Allowed Security Groups' on the right.

The report will be in the left 'Restricted Security Groups' pane and not the right 'Allowed Security Groups' pane as you'd expect!

Whoever wrote the report sub-system wasn't paying attention, and set a sense flag to 'Y' so that instead of the 'Allowed Security Groups' from the Report Type showing up in the Security Group's 'Used By' list, what you see are the 'Restricted Security Groups' that are NOT used to allow access to the report!

All of this can be done just by entries through the GUI, and done without disturbing the user base. It's very low risk.

The benefits are a clean security system thats easy to manage and explain to the user base.

You are undoubtedly going to want to customize the base model. The key point is to start with a solid security model and then, and only then, add the minimum amount of customization. Keep it simple!

Dave is available on contract to assist with any of this. You can contact him at this email address.

Kintana™ and 'HP PPM (Project and Portfolio Management)'™ are trademarks of Hewlett Packard Corporation.