Rego University: Security Models, CA PPM (CA Clarity PPM)

www.regoconsulting.com Phone: 1-888-813-0444
Security Models That Work
Security Models,
CA PPM (CA
Clarity PPM)

2
Creating a security model that is overly complex and difficult to
modify and maintain is easy to do when trying to implement
tight security within CA PPM. In this session, you will learn
some key concepts when designing and implementing
security. Additionally, Rego’s team of experts will share tips
and tricks for automating security, as well as ways to monitor
the CA PPM rights that individuals have.
Class Description

3
● What’s your comfort level with security concepts?
● What’s your comfort level with security strategies?
● Do you have an established CA PPM system or are you newly
implementing?
● What do you hope to get out of this class?
● What real world issues with your security model would you
like to resolve?
● What do you want to share? What have you lived through to
tell the tale?
Quick Poll

4
● Security Overview
● Terminology
● The 9 paths to giving a right
○ Pro’s and Con’s of each
● Automatic vs. Manual Rights
● Explicit vs. Implied Prerequisites
● Weird rights
● Security Quiz
● Tips on creating a security model
● How to analyze and overhaul an existing security model
Agenda

5
5
Technical vs. Application Security
● Technical Security (Before you get logged into CA PPM)
○ Server Level: VPN, Firewall, etc.
○ Database Level: Data Encryption, Password Protect Files
○ User: Passwords Tied To Global Authentication
● Application Security (Once you have logged into CA PPM)
○ Restrict Data (restrict who can see certain projects or resources) –
View and Edit, Portlets and Reports
○ Restrict Functions (restrict who can see a link or portlet) – Processes,
Jobs, Objects, Administration
○ CA PPM is a cumulative “Rights” based security model.

6
6
Partitions vs. Security Rights
● Why would you use partitions vs. traditional security?
1. Partitions
• Advantage: Can secure even administration within the tool, so the only way
to see another organization’s data is by querying the DB directly.
• Advantage: Can have completely different (There are additional items that
can be partitioned, but these are the ones that are really used):
» Object user-defined attributes (fields)
» Object views (Properties, List Column, and List Filter)
» Lookup values
» Portlets and Processes
» Note: Reports, Jobs, and NSQL queries cannot be partitioned, so security groups are still
needed even if partitions are used.
2. Security Groups and OBS Rights
• Advantage: Lower cost to administrate and setup
• Advantage: Can collaborate on projects – giving access to resources in both
organizations.

7
7
Security Architecture
OBS
Rights
Global
Rights
Automatic
Rights
Instance
Rights
Person
Group
OBS Level

8
● “Principal”
○ Who has the right? Which specific user or which
groups of users?
• A specific single user could be given a right = Resource
right
• An arbitrary set of users can be grouped into a Security
Group and given a right = Group right
• Or , since users are already grouped together by the
OBS that they are in, a right could be given to an OBS
grouping of users = OBS Principal right
 The OBS has to associated with Resources and enabled
for security
Terminology

9
● “Target”
○ What does the user (or set of users) have rights over?
• The Principal can have rights over a specific record in the CA PPM
system (rights over a specific project or rights over a specific user)
= “Instance Rights”
• Since records are usually grouped together by their OBS
assignment, then a Principal can have rights over a set of records
that are grouped together the record’s OBS setting
 The OBS does not have to be security enabled (that setting is for the Principal
side of rights
• Or a Principal can have rights over all records of a particular kind (over all
Projects, over all Applications, etc)
Terminology

10
So 3 Principal kinds times 3 Target Kinds = 9 “paths” to granting a right to
someone over something. Examples:
● Resource Bob has a right over Instance “Project X”
● Resource Sarah has a right over all Applications in OBS “Department X”
● Resource Joe has a right over every single Resource in the System (Global)
● The PM Group has a right over Instance “Portlet X”
● The Dept Z RM Group has rights over all Resources in Department Z’s OBS
● The Admin Group has rights over all Processes Globally
● Everyone in OBS X has rights over a certain Project (Instance) for tracking
Admin Time in that OBS
● Everyone in OBS X has rights over projects in that same OBS
● Everyone in the PMO OBS has rights over all Projects Globally
The 9 (or 25) paths to giving a right

11
● OBS Principal Rights
○ Handy because it saves time creating a group that represents a group
of resources that are already in an OBS
○ If someone is added to a group – they automatically get certain rights.
This could be good or bad (anyone with ability to change a resource’s
OBS could change them to any OBS and thus get those rights)
○ Performance issues sometimes occur – more logic to analyze
especially if using “Modes”
○ Often better to automate the synching of OBS’s with Groups
Pro’s and Con’s of the 9 Paths

12
● OBS Target Rights
○ Performance Issues, especially if using Modes
• Especially if doing OBS Principal over OBS Target rights
● Not simple to set up
○ No relative rights in CA PPM. Can’t say “all users in any OBS can do X in
their OBS”. You have to go to each node on the Principal side and map it to
the Target side
○ Every OBS change means updating and remapping OBS to OBS
● Workaround
○ There is a single security view in CA PPM that does not perform well. Any
OBS and instance rights are added to this single view and used when you
call for @SECURITY@ in a portlet. If you have lots of OBS rights, it will slow
down performance vs. global rights. If you can do global view – do it. If
not, can write custom security call to improve performance.
Pro’s and Con’s (cont’d)

13
● Resource and Instance rights
○ Can be done temporarily for exceptional situations
○ Must be tracked or the right will linger off the radar beyond the time it
should have
○ Processes are available or can be built to automatically grant. Make
sure they automatically revoke as well.
● Global rights
○ Best performance – no logic to take care of, but benefit can be
counter-balanced if their screens will also pull back all data (example:
Timesheet Approver right can slow down their ability to even enter up
their own time)
Pro’s and Con’s (cont’d)

14
● We’ve been demo’ing Manual ways of granting rights
○ Manual giving a right to a Principal over a Target
● There are also automatic rights
○ Example: if you are marked as another user’s RM you get to edit their
calendar
○ Two kinds of automatic rights
• Revocable
 Resource – Enter Time (for themselves)
• Irrevocable
 User Favorites Menu - Edit
Automatic vs. Manual

15
● Some rights are useless without another right (example: does
no good to give someone the rights to create Security Groups
if they can’t get to the Admin side of the system)
● Therefore the other right has to be given
○ Sometimes CA PPM will automatically (implicitly) give the pre-
requisite Rights [will not show in list of rights in the UI]
• Example: Give someone “Administration – Authorization” to manage
rights of other users and groups and they will get Administration access
but doesn’t show in list of rights
○ Sometimes CA PPM will NOT automatically give the pre-requisite right
and you must Explicitly grant it for the original right to mean anything
• Example: “Administration – Partition Models” – means nothing unless you
manually also give “Administration Access”
Implicit vs. Explicit Pre-requisites

16
● Collaborator Manager rights
○ Doesn’t show in security model screens. Only the current Collaboration Manager can make someone else a
Collaboration Manager
● Incident Security
○ In order to gain access to incidents, incident categories must be created within the administration section
(Data  Incidents). Next, a person/group/OBS can be given rights to manage or select the incident category.
● Sub-page Security
○ The first step is to mark a sub-page as “secure”. This action will create two rights within the security
administration section – “edit” and “view” for that subpage. These rights can then be given to a
person/group/OBS.
● Field Level Security
○ Read Only Field
• A field can be made read-only. This is useful when it is populated by a process or auto-numbered
○ Locked Field
• A field can be locked or unlocked by the process at certain point(s) in the object lifecycle.
○ Calculated Field
• The editable field can be put on a secure subpage, then a calculated field (based on the editable field)
can be displayed on the main subpage – having the appearance of being read-only
○ Dependent Lookup Field
• This is only available in later versions, but it is possible to have one lookup field display values based
on the value of another lookup field on the same object. This will need to be done with query based
lookups.
Weird rights

17
17
Quiz Time
1. You want to give RMs the rights to add their people onto any project
2. You want to give resources the ability to update % complete on tasks
3. You want to create a set of dashboard links based on the role people have –
some of the portlets are the same between RM and PM
4. You want to have only finance be able to open a project for time entry
5. You want to have the stage field controlled by a process where no one can
update (but later the users will come back asking to allow the PMO to
manually update the stage, then lock again)
6. You want to give RMs the right to edit the time of the people that report to
them
7. You want to give executives the rights to see all projects but edit none
8. You want directors to have view rights to all, but edit rights only to their
organization for resources and projects
9. You want the business to only be able to see ideas they sponsor
10. You want one business unit to select from 3 project types, while another
selects from 2 of the same and one different type
11. You want to give ability for local admins to reset passwords

18
Tips on Creating a Security Model

19
1. Understanding what each right means
○ The 9 paths
○ The definition of each right
○ Understand licensing implications of different rights
2. Define Security Roles
○ Not same as Primary Role or their Security Groups
○ Theoretical, not in the system
○ Example: Timesheet user is not a Primary Role and it may mean membership
3. Pick a philosophy (will discuss later)
4. Do it on paper first (your security model design)
○ Can use ootb groups as suggestions or material to brain chew on but you will
likely not use them.
Steps to Implement a Security Model

20
5. Set up the model in CA PPM
○ Can be done concurrent with other implementation coding
○ Create dummy data
○ Create dummy users – one per “role” (not same as a group)
6. Look at dummy users in Licensing Portlets
○ Challenge any discrepancies to published PDF’s
○ Do the math of license implications of your current design
7. Log in as dummy user and Test and simulate
○ Can you see what you should in that role?
○ Can you NOT see what you shouldn’t see (often neglected in test scripts)
Steps to Implement a Security Model

21
● Underlying Philosophies
○ Open by default, restrict only when needed
○ Closed by default, open only when absolutely needed
○ Blended
• Open by default for everything but Financial information (pay grades, rates,
etc) which should be fully closed
● Choice of philosophy
○ Often driven by standards and compliance (SOX)
○ Otherwise – blended approach works best. Closed by default creates
overhead for the Support team that isn’t proven to be necessary. Also
causes system to have to run more logic to determine access.
• This means Global rights but within the limits of their licensing (no need to
give timesheet users the rights to manage projects if they don’t)
● Auditing versus Security
○ If someone is just worried that someone else will alter a field and no one
will know who did, then consider auditing
• Too much auditing can cause performance issues on some versions of CA PPM
Exposure Philosophies

22
● Licensing Portlets
● Audit them periodically and compare results to licensing PDF’s
to validate what the portlet seems to be saying
Licensing Implications

23
23
Feedback on Security – Pain or Gain
● What areas are causing you pain in security?
● What are some lessons learned in security?
● Other questions?

24
● Why?
○ Licensing problems (under or overutilized licenses)
• CA PPM doesn’t warn you when you just increased your license usage to a
new level
○ User complaints about speed of getting access they need
○ The support team has lost track of what’s going on and who
can/should see what and not see what
○ Maintaining the model is too time consuming
Overhauling an Existing Security Model

25
● Collect pains
○ Not just your own!
○ Your end users
○ Your support teams’
○ Your stakeholders
● Run licensing portlets to see if you have a problem there (or
underutilized licenses) when compared to your licensing
agreement
● Derive a paper security model design to represent what
should be in the system if you don’t have one.
○ If you do have one, update it
● Query the database to extract the real world data model
○ Pivot tables useful
How to analyze and overhaul an
existing security model

26
● Compare reality to the design and fix the paper design to
match what was really needed or make a plan to modify
reality to match the design (or both)
● Review the collected pains and incorporate their resolution
into your model design
● Execute any remediation plan in non-Prod first
● Run licensing portlet to see if all is now well in Non-Prod
● Whenever modifying the model – test, test, test
○ Ex: Don’t assume that a right given to an OBS principal will work same
exact way when given to a User Group
(cont’d)

27
● Dummy users for testing or logging in as sample users
● Testing includes performance testing in a large user-base
system
● UAT is good so users aren’t surprised
● After implementing into Prod, run License Portlets again
(cont’d)

28
● Overhaul security model to make it easier (steps already
covered)
● Automation
○ Turnkey – RegoXchange
○ Roll your own
● Federating access control
○ Or at least authorization
Improving Maintenance

29
● If you change or add something to the system (enhancements like new
portlets or objects), remember to think through the security implication
○ Who should be able to create this kind of object? Edit it? Run it?
○ Often forgotten
• To grant rights to new subobjects
• To use rights to control the ability to see subpages
● When your develops code something, use record-level security
○ Running a portlet right is different than only showing the rows that the user is
supposed to see
● Give feedback to CA
○ There is often a workaround that you can get used to but it is still a work around
○ GUC, Ideas, Product Advisory Council
● Periodically audit compliance to your security model design
○ And do a license comparison and compare to your last audit
● When upgrading – test, test, test
○ War story – pay grade exposed when an explicit requirement became implicit
Other tips

30
● Define your process for granting rights
○ Have an authorization step(s)
• But include rules for what is always ok and no need for authorization
○ Include a step to check the user’s license level before and after
Other tips (cont’d)

31
Questions
Contact US
888.813.0444
Email Contact
info@regoconsulting.com
Web Site
www.regoconsulting.com
Thank you.

Rego University: Security Models, CA PPM (CA Clarity PPM)

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Rego University: Security Models, CA PPM (CA Clarity PPM)