Contextual Security Management

1
Contextual Security Management Technical Overview
2
Presentation Structure

• Key Features
• Installation
• How to turn it on
• Role Management
• How it works
• What changed
• ACL Rules
• Structure
• Hierarchy
• Row vs Field Rules
• Debugging
• Conversion Utilities

3
Key Features

• Context Based
• Bob can update tickets he opened but not tickets
  that Abe opened
• Contractors can only update tickets assigned to
  their company, FTEs can update all tickets
• Aware of Object Hierarchy
• Rules on low level objects (incident) can
  override the behavior of higher level rules
  (task)
• ACL Based

4
Installation

• Its a plugin
• com.glide.role_management
• Log in as maint
• Plugins
• Activate
• Log out, then back in again
• Lets do it

5
What just happened

• Contextual Security Manager installed
• Menus
• Data
• Code
• CSM set as system security manager
• System Properties -gt Security -gt Security Manager
• Roles were automatically upgraded to new data
  structures

6
Role Management

• Roles are now first class entities
• Records in the database
• Related to users via a Many to Many
• Accumulated Roles field retired
• No longer updated or used
• Roles can be granted to
• Users
• Groups
• Some examples

7
Anatomy of an ACL Rule Part I What are we
securing?

• Type
• What are we securing?
• Always record for current version
• Operation
• create
• read
• write
• Delete
• Name
• lttablenamegt or lttablenamegt.ltfieldnamegt

8
Anatomy of an ACL Rule Part II How are we
securing it?

• Condition
• category hardware
• Script
• gs.getUser() current.opened_by
• Roles
• Admin
• Lets build some rules

9
Debugging

• Turn it on (menu)
• Impersonate another user
• Gotchas
• Admin can see anything (security does not apply)
• Multiple rules at a given level are ORd e.g.
  given two read rules on incident.category, if
  either is true, you can read it
• Row rules and field rules are ANDd e.g. if you
  cant write the row, the fact that you can write
  the field is immaterial
• Create for a new record, write for an existing
  record

10
Performance considerations

• Field rules run on every field on every form or
  each cell on each table
• Keep them simple
• Avoid database IOs if at all possible
• Use the helper scripts (theyre cached)
• gs.getUser().isMemberOf()
• gs.getUser().getRecord().getValue(ltsome fieldgt)
• Each field rule test row rule as well so no real
  benefit to moving expensive checks to the row

11
Quirks Known Issues

• Aggregate reports do not enforce row visibility
  rules so invisible rows show up in the
  aggregate
• A list of 100 rows, of which only 10 are visible,
  shows only 10 rows. We do not go out and search n
  rows until we find 100 that we can see