www.regoconsulting.comphone: 1-888-813-0444 clarity security models that work clarity security...

www.regoconsulting.com Phone: 1-888-813-0444

Clarity Security Models That Work

Clarity 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 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 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

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 ArchitectureOBS

Rights

GlobalRights

AutomaticRights

InstanceRights

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 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)

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

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 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”

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 Time1. You want to give RMs the rights to add their people onto any project2. You want to give resources the ability to update % complete on tasks3. 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 entry5. 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 them7. You want to give executives the rights to see all projects but edit none8. You want directors to have view rights to all, but edit rights only to their

organization for resources and projects9. You want the business to only be able to see ideas they sponsor10. You want one business unit to select from 3 project types, while another selects

from 2 of the same and one different type11. 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 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)

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 Clarity

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)

• 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

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

Overhauling an Existing Security Model (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

Overhauling an Existing Security Model (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 US888.813.0444

Email [email protected]

Web Sitewww.regoconsulting.com

Thank you.

mailto:[email protected]

http://www.regoconsulting.com/

www.regoconsulting.comphone: 1-888-813-0444 clarity security models that work clarity security...

Documents

security rights

security groups

security concepts

security strategies

traditional security

tight security

clarity security models

clarity rights