Clarity Security Models That Work - PowerPoint Presentation

1. Clarity Security Models That WorkClarity Security Models

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 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.Class Description

3. 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?Quick Poll

4. Security OverviewTerminologyThe 9 paths to giving a rightPro’s and Con’s of eachAutomatic vs. Manual Rights Explicit vs. Implied PrerequisitesWeird rightsSecurity QuizTips on creating a security modelHow to analyze and overhaul an existing security modelAgenda

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

6. 6Partitions vs. Security RightsWhy would you use partitions vs. traditional security?PartitionsAdvantage: 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 ProcessesNote: Reports, Jobs, and NSQL queries cannot be partitioned, so security groups are still needed even if partitions are used.Security Groups and OBS RightsAdvantage: Lower cost to administrate and setupAdvantage: Can collaborate on projects – giving access to resources in both organizations.

7. 7Security ArchitectureOBS RightsGlobalRightsAutomaticRightsInstanceRightsPersonGroupOBS 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 rightAn arbitrary set of users can be grouped into a Security Group and given a right = Group rightOr , 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 rightThe OBS has to associated with Resources and enabled for securityTerminology

9. “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 rightsOr 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 OBSThe Admin Group has rights over all Processes GloballyEveryone in OBS X has rights over a certain Project (Instance) for tracking Admin Time in that OBSEveryone in OBS X has rights over projects in that same OBS Everyone in the PMO OBS has rights over all Projects GloballyThe 9 (or 25) paths to giving a right

11. OBS Principal RightsHandy because it saves time creating a group that represents a group of resources that are already in an OBSIf 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 GroupsPro’s and Con’s of the 9 Paths

12. OBS Target RightsPerformance Issues, especially if using ModesEspecially if doing OBS Principal over OBS Target rightsNot simple to set upNo 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 sideEvery OBS change means updating and remapping OBS to OBSWorkaroundThere 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.Pro’s and Con’s (cont’d)

13. Resource and Instance rightsCan be done temporarily for exceptional situationsMust be tracked or the right will linger off the radar beyond the time it should haveProcesses are available or can be built to automatically grant. Make sure they automatically revoke as well.Global rightsBest 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 TargetThere are also automatic rights Example: if you are marked as another user’s RM you get to edit their calendar Two kinds of automatic rightsRevocableResource – Enter Time (for themselves)IrrevocableUser Favorites Menu - EditAutomatic 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 givenSometimes 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 rightsSometimes Clarity will NOT automatically give the pre-requisite right and you must Explicitly grant it for the original right to mean anythingExample: “Administration – Partition Models” – means nothing unless you manually also give “Administration Access”Implicit vs. Explicit Pre-requisites

16. Collaborator Manager rightsDoesn’t show in security model screens. Only the current Collaboration Manager can make someone else a Collaboration ManagerIncident SecurityIn 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 SecurityThe 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 SecurityRead Only FieldA field can be made read-only. This is useful when it is populated by a process or auto-numberedLocked FieldA field can be locked or unlocked by the process at certain point(s) in the object lifecycle. Calculated FieldThe 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-onlyDependent Lookup FieldThis 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. 17Quiz TimeYou want to give RMs the rights to add their people onto any projectYou want to give resources the ability to update % complete on tasksYou 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 entryYou 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 themYou want to give executives the rights to see all projects but edit noneYou want directors to have view rights to all, but edit rights only to their organization for resources and projectsYou want the business to only be able to see ideas they sponsorYou want one business unit to select from 3 project types, while another selects from 2 of the same and one different typeYou want to give ability for local admins to reset passwords

18. Tips on Creating a Security Model

19. Understanding what each right meansThe 9 pathsThe definition of each rightUnderstand licensing implications of different rightsDefine Security RolesNot same as Primary Role or their Security GroupsTheoretical, not in the systemExample: Timesheet user is not a Primary Role and it may mean membershipPick 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.Steps to Implement a Security Model

20. 5. Set up the model in ClarityCan be done concurrent with other implementation codingCreate dummy dataCreate dummy users – one per “role” (not same as a group)6. Look at dummy users in Licensing PortletsChallenge any discrepancies to published PDF’sDo the math of license implications of your current design7. Log in as dummy user and Test and simulateCan 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 PhilosophiesOpen by default, restrict only when neededClosed by default, open only when absolutely neededBlendedOpen by default for everything but Financial information (pay grades, rates, etc) which should be fully closedChoice of philosophyOften 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 SecurityIf someone is just worried that someone else will alter a field and no one will know who did, then consider auditingToo much auditing can cause performance issues on some versions of ClarityExposure Philosophies

22. Licensing PortletsAudit them periodically and compare results to licensing PDF’s to validate what the portlet seems to be sayingLicensing Implications

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

24. Why?Licensing problems (under or overutilized licenses)Clarity doesn’t warn you when you just increased your license usage to a new levelUser complaints about speed of getting access they needThe support team has lost track of what’s going on and who can/should see what and not see whatMaintaining the model is too time consumingOverhauling an Existing Security Model

25. Collect painsNot just your own!Your end usersYour support teams’Your stakeholdersRun licensing portlets to see if you have a problem there (or underutilized licenses) when compared to your licensing agreementDerive 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 itQuery the database to extract the real world data modelPivot tables usefulHow 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 designExecute any remediation plan in non-Prod firstRun licensing portlet to see if all is now well in Non-ProdWhenever modifying the model – test, test, testEx: Don’t assume that a right given to an OBS principal will work same exact way when given to a User GroupOverhauling an Existing Security Model (cont’d)

27. Dummy users for testing or logging in as sample usersTesting includes performance testing in a large user-base systemUAT is good so users aren’t surprisedAfter implementing into Prod, run License Portlets againOverhauling an Existing Security Model (cont’d)

28. Overhaul security model to make it easier (steps already covered)AutomationTurnkey – RegoXchangeRoll your ownFederating access controlOr at least authorizationImproving Maintenance

29. If you change or add something to the system (enhancements like new portlets or objects), remember to think through the security implicationWho should be able to create this kind of object? Edit it? Run it?Often forgottenTo grant rights to new subobjectsTo use rights to control the ability to see subpagesWhen 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 seeGive feedback to CAThere is often a workaround that you can get used to but it is still a work aroundGUC, Ideas, Product Advisory CouncilPeriodically audit compliance to your security model designAnd do a license comparison and compare to your last auditWhen upgrading – test, test, testWar story – pay grade exposed when an explicit requirement became implicitOther tips

30. Define your process for granting rightsHave an authorization step(s)But include rules for what is always ok and no need for authorizationInclude a step to check the user’s license level before and afterOther tips (cont’d)

31. QuestionsContact US888.813.0444Email Contactinfo@regoconsulting.comWeb Sitewww.regoconsulting.com Thank you.