Moving Beyond Implementation: Authorization

1
Moving Beyond Implementation Authorization

• Tom Barton, University of Chicago
• Keith Hazelton, University of Wisconsin - Madison

2
Outline

• Why have common infrastructure to manage
  authorization?
• Case study in group management U Chicagos
  USITE computer labs
• a tour of Grouper
• Privilege management with Signet
• How do you know when to use groups and when to
  use privileges?

3
A day in the life

• Hey guys, we need to have alums and hospital
  staff access some of our services and apps
  online! ?
• Groan as you gradually recognize the amount of
  policy, organizational, and technical work to
  coordinate management of identifiers and work out
  unifying authentication service options. ?
• Groan as you gradually realize that current
  access controls are too often based solely on
  ability to authenticate. ?

4
Scenario General Services

• General services the need to serve more loosely
  affiliated constituencies breaks the simple log
  in and get it all model
• Long list of afflicted services
• Mailbox access, mail redirection, mail list
  management, computer lab access, network access
  (modem, wireless, wireline, VPN), access to
  licensed resources, shell accounts, IFSs, web
  apps content, calendar, desktop management,

5
Scenario Administrative Services

• If you dont have a comprehensive and
  vendor-integrated ERP, youve got a set of
  systems each with their own security management
• The more standalone security management domains
  youve got the harder to implement authority in
  accord with organizational policy
• Setup new user
• Change of status
• Termination

6
Scenario IdM Adoption

• To further the adoption of centrally maintained
  core middleware (netID or IdM system) by IT
  operators large small outside of central IT,
  you need to let them manage some of the
  information conveyed by that middleware to meet
  their own needs.

• Proxy access by local tech support
• Group info
• Password policy assignment

7
Scenario - Portal

• The portal through which youd like to provide
  services needs to know enough about each persons
  roles to present them with customized views.
• Major affiliations
• Activity-specific roles

8
Scenario Messaging Collaboration

• You want to make it easy for people to share
  documents among selected others. Poor options
• Send documents by email
• Share them with the world on a web site
• Otherwise, its necessary for people to be able
  to list their collaborators somewhere available
  to the infrastructure through which the sharing
  happens.
• Everything from shared mail folders thru mail
  lists and group chats to LMSs and IFSs.
• Gee, itd be even nicer if that list wasnt tied
  directly to each collaborative or messaging
  system.

9
Scenario Workflow

• The workflow approach
• define business processes
• route work items through processes
• assign people to roles in processes
• integrate processes into app systems
• Some workflows are about access management
• Manage access to admin systems
• Manage authority to maintain portion of network
  address plan
• Manage access to clinical systems or others
  containing ePHI
• All workflows rely on roles, i.e., authority

10
Scenario Mature NOS

• Our Active Directory or Novell deployment is
  mature and has a valuable set of groups. Now
  theyre needed elsewhere too.

11
Scenario - Yours

• Audience participation Your scenarios of this
  sort that Ive missed.

12
Common Authorization Management Infrastructure

• UIs for humans and APIs for automation
• A registry housing authorization data
• Complement to the Person Registry
• Many authorities update the registry
• Many applications consume data provisioned from
  the registry
• Authorization registry houses
• Groups in a Group Registry
• Highly structured privilege objects in an
  Authority Registry

13
Core (authZ) middleware values

• Ease the burden of end users
• Ease the burden of authorities
• Ease the burden of IT providers
• Focus operational responsibility on a smaller
  number of people specifically tasked
• Reduce the number of locations in which critical
  business logic resides
• Reduce cost and time to respond to change in user
  status
• Enable adoption of security lifecycle
  management policies across the suite of
  integrated systems
• Increase number of integrated systems because the
  middleware meets more requirements, ie, authZ in
  addition to authN and management of basic
  identifiers.

14
The Authorization Space

• As everyone knows by now
• Authentication says who you are, authorization
  says what you can do. OK as a tag line, but not
  for architecture ...
• A higher-level definition
• Configuration and operation of systems so actions
  in support of organizational goals are permitted
  and other actions are prohibited ... or
• Representation and enforcement of organizational
  policy in software systems
• Covers all scales from macro-level policy
  (comply with HIPAA) to micro-level (user X can
  access file Y)

15
U Chicagos USITE access problem

• Must control access to computers in labs
  independent of ability to authenticate
• I came along with a ? and said Hey guys, we need
  to give alums and hospital staff access to some
  of our stuff!
• U Chicagos Networking Services Information
  Technologies (NSIT) established the Identity
  Management Working Group to solve this type of
  problem
• Youll see nsit and usite in names of things
  to follow

16
USITE access policy

• Students
• 23 categories of current students
• Some entitle USITE access, some disenfranchise,
  others fail to entitle
• Time of year dependency for some categories
• Current faculty staff are entitled
• Other more loosely affiliated people are not
  entitled
• Exceptional administrative admits and denies
  across all categories above

17
Use of group management

• Various elemental categories of people relevant
  to USITE access policy are modeled as groups
• Subgroups are used to roll-up effective admit or
  deny status
• Some groups are automatically managed, others
  manually
• Some roll-up groups are manually managed to deal
  with time dependency or change in access policy

18
Groups model for USITE access
ACL is usite_eligible but not usite_barred
usite_eligible (manual)
usite_barred (manual)
admin_admit (manual)
admin_deny (manual)
ucfaculty (auto)
ucstaff (auto)
categories of barred students (auto)
categories of entitled students (auto)
time dependent student categories (auto)
19
Management related groups

• Management privileges for manually managed groups
  also need to be managed!
• So, more groups list who has what authority in
  managing groups that mediate USITE access
• Director of Learning Environments
• Lab Managers
• Student staff

20
Data flow Groupers role in USITE access
SIS
lab
HR
Person registry
LDAP
Group registry
Dir. Learning Environments
uid jdoe ucAffiliation isMemberOf
Grouper API
Lab Managers
Student staff
21
Grouper groups

• Attributes of groups
• Names name, displayName, guid
• Description
• Members
• Possible to extend the set of attributes to
  support groups with more specific purposes
• Subgroups, compound groups, and aging are
  supported
• Stored in an RDBMS, the Group Registry

22
Group namespaces

• Groups are created within (a hierarchy of)
  namespaces
• Namespaces scope the authority to create and name
  groups
• The Director of Learning Environments can rule
  over an empire of groups within a namespace
  delegated to her
• The namespace delimiter can be configured for
  different effect
• URN style example nsitusiteadmin_admit
• Pathname style example /nsit/usite/admin_admit

23
Grouper privileges

• Access privileges
• Who has what access (read, write) to a groups
  attributes
• Naming privileges
• Who can create a group in each namespace
• Who can create a new namespace subordinate to an
  existing one
• Privilege interfaces are abstracted so that sites
  can roll their own if they dont want to use
  Groupers built-in privilege management
• Subgroups, compound groups, and aging can be used
  to manage privileges with built-in capability

24
Access privileges

• VIEW controls to whom a group is visible or
  hidden
• READ information, especially membership, about a
  group
• UPDATE membership and administer VIEW, READ,
  UPDATE privileges
• ADMIN can modify everything, including group
  name, description, access privileges, and can
  delete the group
• OPTIN can add self to the members list
• OPTOUT can remove self from the members list

25
Naming privileges

• CREATE a group in a given namespace
• STEM privilege in a given namespace enables
• Assignment of CREATE and STEM privileges for the
  namespace
• Creation of subordinate namespaces

26
Three ways to distribute group management

• Create a group and assign someone UPDATE
  privilege to it
• Manage the groups membership
• Create a group and assign someone ADMIN privilege
  to it
• Manage who manages the groups membership and who
  can see what about the group
• Create a namespace and assign someone STEM
  privilege to it
• Manage who can create groups with constraint on
  how they are named

27
USITE rolling out Grouper

• Make an nsitusite namespace in the group
  registry
• Grant STEM privilege for nsitusite to the
  Director of Learning Environments
• Create manually managed nsitusite groups
• Automatically maintain student, faculty, staff
  related groups in other namespaces as part of IdM
  operation
• Assign privileges to all of these groups

28
USITE group access privileges
(unqualified names in nsitusite namespace)
usite_eligible Adir_learning_env V,Rall
usite_barred Adir_learning_env V,Rall
admin_admit Uusite_manage V,Rusite_view
admin_deny Uusite_manage V,Rusite_view
ucfaculty V,Rall
ucstaff V,Rall
categories of barred students
Vall
Vall
Vall
categories of entitled students
Vall
Vall
time dependent student categories
Vall
Vall
Vall
Vall
29
USITE group management privileges(unqualified
names in nsitusite namespace)
30
Personal groups

• Any user can create groups named
  personalusernamegroupname
• Good or evil?
• Yeah! Low overhead to let everyone do groups
• Booo! Valuable institutional data squirreled away
  in unknowable spaces that go away
• Configuration
• on/off
• Root directory for personal namespace (personal
  above)

31
Signet
32
Signet Subsystems

• Financial system
• Student system
• HR system
• Network address plan management
• Network access management
• Research administration
• Clinical resources
• IdM UI (Person Registry)
• Signet (Authority Registry)
• Grouper (Group Registry)

• Define domains of ownership and responsibility
• Reflect real world boundaries
• Can be large or small
• Examples

33
Authority elements by example
34
Privileges building blocks

• Business view
• Subsystems
• Categories
• Functions
• Scope
• Limits
• Prerequisites
• Conditions

• System view
• Permissions
• Assignment to
• Individual
• Group
• Proxy assignment

35
Nutshell Description

• Analysts write XML descriptions of business views
  and store them in the Authority Registry
• Signet UI presents business views found in the
  Authority Registry
• Authoritative persons use the Signet UI to assign
  privileges and delegate authority across all
  subsystems in which they have any authority
• Signet UI stores assignments in the Authority
  Registry
• XML permissions documents are exported from the
  Authority Registry, transformed, and provisioned
  into integrated systems and infrastructure
  services

36
Function/Permissions
37
Permissions integration - provisioning
38
Permissions integration - infrastructure
39
Signet components
Yellow institution provided
40
Signet Grouper Availability

• NSF Middleware Initiatives 6th release of
  componentry early this December will include
• Initial release of Grouper API. Supports basic
  group management by automation processes
• Demo release of Signet
• U Bristol is working on the Grouper UI
• 2nd Grouper release will include it
• Production ready release of Signet anticipated
  middle of 2005

41
Lightweight AuthZ Characteristics

• Either
• has a large constituency or
• uses broadly deployed technologies
• Relationships with the organization
  (affiliations) are a principal determinant of
  access
• No single business unit is cognizant of all
  required affiliations

42
Three Channel Lightweight AuthZ Model

• Major affiliations
• Source of authority admin systems business
  logic in metadirectory processing
• Minor (ad hoc) affiliations
• Source of authority mix of central business
  logic and decentralized manual and automated
  sources
• Per user, per service positive or negative
  exceptions
• Source of authority select administrative
  access. Eg, Info Security Officer

43
Major affiliation

• 10-20 values in a conservatively managed
  vocabulary
• Widely understood semantics
• Relatively static semantics
• Satisfies 80 of access control needs for broadly
  used services
• Stake will go deeply into the ground
• Egs faculty, facultyexpected, student,
  studentadmitted, staff, staffcasual,
  staffregular, associate, hospital, alum
• ucAffiliation LDAP attribute

44
Minor affiliation

• Maintained by distributed management of groups
• Semantics are less widely understood or more
  dynamic
• Satisfies 80 of needs for locally offered
  services
• Group names are reflected into isMemberOf LDAP
  attribute
• No value syntax beyond whatever convention for
  names will apply
• Use Grouper!

45
Heavyweight AuthZ Characteristics

• Authorize by identity, not (just) by affiliation
• Human judgment is key
• Requirements for
• Delegation of authority
• Designation of limited privileges
• Authority is structured
• Categories of functions resolve into entitlements
  mapped to per-system privileges
• Limits, prerequisites, conditions, scope
• Ratio of users/authorizers is relatively small

46
Resources

• http//middleware.internet2.edu/dir/groups
• http//middleware.internet2.edu/signet
• hazelton_at_doit.wisc.edu
• tbarton_at_uchicago.edu

47
Notes EOS marker

• Signet schtick with X example
• How to know when group mgmt or priv mgmt is
  appropriate to a given scenario
• laZ model as one way to recognize the difference
• Some RLBob slidage goes here (signet grouper)
• Where does provisioning fit into this picture
  big picture gag

48
Groups facilitate

• Customization application UI tailored to users
  affiliations with the organization
• Authorization
• Lightweight - relationship info feeding access
  decisions
• Heavyweight - assignment of structured
  privileges to groups
• Messaging, scheduling, collaboration
• Departments, courses, programs, cmtes, teams,
• Posix naming services

49
Group management issues

• Coordinating many sources of information
• Provisioning groups in many locations
• Supporting several styles of access to group
  membership information
• Aging of groups and of memberships
• Use of subgroups vs. effective membership
• Referring to set theoretic combinations of groups
  (compound groups)
• Privacy visibility requirements

50
Grouper v1 features

• API UI for basic group management
• Create, read, update, delete, import, export
• Distributed management
• Subgroups compound groups
• Aging of groups and memberships
• Abstracted interfaces for
• Group and directory privileges
• Subject lookup
• Last activity

51
Grouper deliverables

• U Chicago - Java API
• U Bristol - Java UI
• You contributed loaders connectors
• Subject Lookup implementation
• jointly with Signet project
• Group Registry creation scripts sample batch
  import/export scripts
• Documentation

52
Grouper releases