Advanced CAMP: BoF Summaries

1
Advanced CAMPBoF Summaries
2

• Role-based Access Control (RBAC)

3
RBAC What and Why?

• What?
• NIST RBAC model introduced
• Role is an abstraction of a job function.
• Role is not a job title.
• Role privileges flow toward root while
  restrictions tend to flow toward leaf
• Why?
• Opportunity to leverage existing metadirectory or
  data warehouse to automatically provision roles,
  at least to a good degree.
• Potential benefits typical of integrative
  approach
• Less overhead, faster response, uniformity,
  degree of automation
• Automates management of services provisioning for
  a dynamic set of users

4
RBAC Design

• Implementation requirements
• model, data elements, components
• vocabulary for communities and roles
• Need flexible management of roles
• Number of roles necessary is dependent on
  department
• Need to manage the number carefully
• The closer you are to the root of the tree
• the more privileges you have
• Stanford has about 200 roles and the ability to
  delegate access privileges if user is closer to
  root of tree

5
RBAC Issues

• Separation of Duties
• Can apply for travel, but cannot approve my own
  travel
• Static vs. Dynamic Roles vs.
• Limitations on role assignment
• Limitations on session-based privileges
• Possible mappings of some RBAC data elements to
  directories
• Natural mappings to users, groups of users,
  permissions??, roles, some role hierarchies
• Less natural Sessions, operation, object,
  permissions??

6
RBAC Issues

• Department differences
• Physician has high access and is a leaf node in
  healthcare.
• Financial staff in leaf nodes have few
  permissions.
• Potential application of separation of duty
  principle to enable physicians with multiple
  roles to adhere to principle of need to know with
  regard to patient data.
• Short-term needs
• Can we Break the Glass and provide permissions
  for special functions to be verified or audited
  later?
• Permissions can be allowed while flagging it for
  examination later.

7
RBAC Issues

• Design considerations
• How much should be automated and how much should
  be left in its current state?
• What is good enough? Maybe ignore exceptions and
  consider an 80 or 90 solution as a start.

8

• Management of Identity

9
Management of Identity Key Issues

• Liability
• Giving accounts w/out verified identity create
  risk.
• Issuing entity could be liable for misuse of
  account.
• How do you accurately identify any entity
  accessing your services?
• How do you verify that identity and who is
  responsible?
• Face to face
• Through documentation
• Sponsorship
• Where is the reconciliation of Identity? It
  varies.
• In the registry
• In data management
• How do you get correct information, how do you
  verify its correct, how do you keep it correct?
• Use SSNs as temporary password to verify
  correctly entered
• Send Birthday mail soliciting updated info
• Set mandatory renewals on accounts

10
Management of Identity Insights

• Directories are bracketed on both ends by
  identity
• Key underpinning of directory services
• Layers on top of directory services
• Surprise!
• Often IT departments are managing identity
• Results from complexity of coordination between
  data owners.
• Need
• Rules and definitions in common between different
  parts of the organization
• Buy-in from key parties supplying identity data.
• Sharing identities (with multiple roles) among
  multiple domains is a multiple campus issue

11

• Affiliated Directories

12
Affiliated Directories Potential Problem Space

• Directories joining data across more than one
  administrative domain
• Super-set or intersection of identities
  "identity math"
• Asserting attributes on behalf of another entity
  three-tier
• Updating and refreshing data in affiliated
  directories automatically

13
Affiliated DirectoriesNecessary Functionality

• Common language for exchanging information
• Identity management
• Authorization
• (Interrealm RBAC?)
• Attribute metadata underlying trust fabric

14
Affiliated Directories Similarities to Current
Systems

• Metadirectories
• Liberty Alliance 1.0 Identity Matching
• Generalized SHAR/AA Interaction
• Useful to many other applications once
  functional

15
Affiliated Directories Possible Scenarios (yet
to be adopted)

• Mapping
• There is a commObject URI in my enterprise
  directory that links me to a commObject in the
  ViDe environment.  The video client wants to
  recognize that the two objects are linked in that
  direction.
• Authorization
• How do we represent and trust an attribute placed
  in Brown's directory that Steven Carmody is a
  member of MACE?  How is this asserted, validated,
  and understood?

16
Affiliated Directories Possible Scenarios
(cont.)

• Pull
• I mirror an identity of Michael Gettes in my
  local directory with additional GRIDperson
  information.  How can I know how volatile this
  information is, or how likely it is to have been
  changed?
• Push
• If I change my name to Bob, how can I ensure that
  anyone else maintaining a version of my identity
  learns this?