Clarity Security Models

1. Clarity Security Models Clarity Security Models That Work

2. Class Description 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 Clarity. 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 Clarity rights that individuals have.

3. Quick Poll • What’s your comfort level with security concepts? • What’s your comfort level with security strategies? • Do you have an established Clarity 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?

4. Agenda • 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

5. Technical vs. Application Security • Technical Security (Before you get logged into Clarity) • 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 Clarity) • 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 • Clarity is a cumulative “Rights” based security model.

6. Partitions vs. Security Rights • Why would you use partitions vs. traditional security? • 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. • 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. Security Architecture OBS Rights Group Global Rights OBS Level Instance Rights Person Automatic Rights

8. Terminology • “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

9. Terminology • “Target” • What does the user (or set of users) have rights over? • The Principal can have rights over a specific record in the Clarity 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)

10. The 9 (or 25) paths to giving a right 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

11. Pro’s and Con’s of the 9 Paths • 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

12. Pro’s and Con’s (cont’d) • 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 Clarity. 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 Clarity 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.

13. Pro’s and Con’s (cont’d) • 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)

14. Automatic vs. Manual • 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

15. Implicit vs. Explicit Pre-requisites • 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 Clarity 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 Clarity 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”

16. Weird rights • 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.

17. Quiz Time • You want to give RMs the rights to add their people onto any project • You want to give resources the ability to update % complete on tasks • 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 • You want to have only finance be able to open a project for time entry • 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) • You want to give RMs the right to edit the time of the people that report to them • You want to give executives the rights to see all projects but edit none • You want directors to have view rights to all, but edit rights only to their organization for resources and projects • You want the business to only be able to see ideas they sponsor • You want one business unit to select from 3 project types, while another selects from 2 of the same and one different type • You want to give ability for local admins to reset passwords

18. Tips on Creating a Security Model

19. Steps to Implement a Security Model • Understanding what each right means • The 9 paths • The definition of each right • Understand licensing implications of different rights • 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 • Pick a philosophy (will discuss later) • 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.

20. Steps to Implement a Security Model 5. Set up the model in Clarity • 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)

21. Exposure Philosophies • 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 Clarity

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

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. Overhauling an Existing Security Model • Why? • Licensing problems (under or overutilized licenses) • Clarity 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

25. How to analyze and overhaul an existing security model • 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

26. Overhauling an Existing Security Model (cont’d) • 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

27. Overhauling an Existing Security Model (cont’d) • 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

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

29. Other tips • 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

30. Other tips (cont’d) • 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

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