Managing Roles & Privileges with Grouper and Signet Middleware

1. Managing Roles & Privileges with Grouper and Signet Middleware Internet2 Spring Members Meeting, April 26, 2006 Tom Barton, University of Chicago Lynn McRae, Stanford University

2. Groups and Roles • Roles and Groups • Who someone is (identity) • People sharing a common trait, e.g., rank or privilege • Roles -- you know it when you see it • Institutional role, e.g., faculty, Dean • Departmental roles, e.g., chair, admin • Professional role, e.g., mathematician, buyer • Project role, e.g., analyst, engineer • Groups • Any collection of people, role-holders or not? • Depends on how you name it? • Role vs group is not what matters

3. Groups and Privileges • Two categories of information are used in making access control decisions • Who you are • aka “roles” • cf RBAC • What you can do • aka “privileges” • cf “value-based authority” • Both types of information are conveyed through attributes about a person • Grouper and Signet are tools that let you enrich descriptive attributes about people in both ways

4. Grouper Grouper • Middleware software/toolkit • User access through a common UI • Program access through a common API • Defines a “Groups Registry” • Brings scattered duplicative groups together for re-use • Allows useful actions on these groups -- group math, group nesting, exclusion criteria • Hierarchical name-space (name stems & substems) • Can leverage existing group information • Supports the creation of new groups • By schools, departments, and individuals! • Distributed/delegated model of control

5. Signet Signet • Middleware software/toolkit • User access through a common UI • Program access through a common API • Brings privilege information together in one place -- a “Privilege Registry” • Central granting, can apply across multiple systems • Central reporting, history, auditing, review • Accessible to managers AND holders of privileges • Independent of specific vendors, systems, releases or technologies • Distributed/delegated model of control

6. Relative Roles of Signet & Grouper • RBAC model • Users are placed into groups • Grouper allows local creation and management of group membership • Privileges can then be assigned to groups • Signet manages privileges to groups (as well as to individuals) • Both “role” and privilege information can be leveraged by systems Grouper Signet

7. Q: Subject + Resource + Action + Context Subject = who wants to take an action, typically a person Resource = what is the action against, e.g., file, building, data, service, etc. Action = what they want to do, e.g., view, modify, enter, approve, run, etc. Context = time of day, academic term, weather, etc. A: Policy interpretation and decision, e.g. Resource and action are available to a group, e.g., Faculty at MIT, Students in a class Available to anyone with “entitlement” for the service Access Control Decision

8. Access Control Decision Resource Subject Identity Provider Service Provider Subject tries to access resource auth’d Context Provider evaluates required identity attributes against rules for resource Provider grants or denies access Rules Policy

9. Palace Access M (MUSKETEER) Who are you? organization=RoyalCourt affiliation=musketeer What can you do? permission=palace_access

10. Identity & Access Management • Each person’s online activities are shaped by many Sources of Authority • Institutional policy making bodies • Resource managers • Program/activity heads • Self • Management of the information it conveys should be distributed • Hook up all of those Sources of Authority to the middleware • Common middleware infrastructure should be operated centrally • Departments/programs/activities should not have to build their own core middleware

11. Big picture

12. Big picture, without Grouper/Signet

13. “Groups is good” WIKI define BIO_X Email Lists define BioX Calendar define Bio-X allow BIO_X allow BioX allow Bio-X What about my team? …my project? …my senior staff? The Boss Identity Management HR Affiliation: faculty Dept: Biology

14. Departmental & other local groups WIKI Email Lists Calendar allow Bio-X allow Bio-X allow Bio-X Grouper Identity Management HR Affiliation: faculty Dept: Biology biology:bio-x biology:bio-x:admin biology:bio-x:staff The Boss

15. Filling the gap CourseWare CS-313 grades Library CompSci resources Allow CS-313 allow CS teaching What about my TAs? … my auditors? … extensions/makeup? External Partner The Professor allow CS affiliates HR Identity Management Affiliation: faculty Instructor: CS-313 SIS Courses Shib

16. Extending Course infrastructure Library CompSci resources CourseWare CS-313 grades allow CS teaching Allow CS-313 Grouper External Partner allow CS affiliates HR Identity Management Affiliation: faculty Instructor: CS-313 SIS Courses U Class:CS-313:TA = isMemberOf: CS-313 Shib The Professor

17. Extending Course infrastructure Library CompSci resources CourseWare CS-313 grades allow CS teaching allow CS-313 Grouper External Partner allow CS affiliates HR Identity Management Affiliation: faculty SIS Courses faculty: CS-313 U class:CS-313:TA = isMember: CS-313 Shib Course Ware The Professor

18. Creating new identity Athletic Facilities Printing Black board faculty, staff, student guest staff, guest student, guest “Friends are here from Europe!” Rula Lenska Identity Management Guest IDs Affiliation: ??? Sib

19. Creating new identity Printing Athletic Facilities Black board student, guest faculty, staff, student guest staff, guest Signet Grouper Identity Management Guest IDs Affiliation: guest blackboard(music103) guestids:guests printing(max100) guestids:admin athletic(gym,after5) Sib effective date expiration date Rula Lenska

20. Distributing control of authority Reporting Reimburse- ments Requisitions who can view who can approve who can spend “Unless the situation is reversed, these …trends will cause serious economic disruptions” A.Greenspan Finance phone Identity Management email ticket Affiliation: staff

21. Distributing control of authority Requisitions Reimburse- ments Reporting who can approve who can view who can spend Signet Finance Identity Management Accounts Affiliation: staff Depts Scope school:dept1 (view,all) school:dept2 (approve,1472,$100) Grouper while staff A.Greenspan B.Bernake

22. Distributing control of authority Reimburse- ments Reporting Requisitions who can spend who can approve who can view Signet Finance Identity Management Affiliation: staff school school:dept scope school:dept1 (view,all) school:dept:unit school:dept2 (approve,1472,$100) Grouper while staff A.Greenspan B.Bernake

23. Grouper Binary info – you’re either in some list or not Locally tweak or combine other groups Identification layer of an encompassing access management scheme Identity- or affiliation-based access control or distribution Signet Structured, qualified info – limits, conditions, scope, … Assignments to individuals as well as groups Delegation and chain of authority essential for access decisions Enable functional, not just technical, people to manage privileges Supports policy control closer to source of authority Audit requirements The duck test…

24. Consider Signet when … • Complex group intersections and hierarchies become cumbersome • Difficult to track who has what and when • Can’t easily move people; need to delete/add • Implementation of related access rules is scattered across systems • different procedures, different contacts, managing changes across areas, over time • You need to coordinate policy, privileges and audit activities across systems

25. Signet & Grouper Overview

26. Grouper Overview • Mix of manual and automation processes manage a common Groups Registry • Stored in an RDBMS • Automation processes provision info from the Groups Registry into LDAP, AD, directly into application-specific databases, wherever the value of the info warrants spending the resources to place it there • Two types of managed objects: groups and naming stems • Groups are created & named with a naming stem • Group management authority is delegatable • By group or by naming stem

27. Grouper Groups • Any “subject” can be a group member or privilegee • Persons, groups, site-defined subject types • Uses Subject API developed by Grouper+Signet teams • Subgroups (now), composite groups (v1.0), and aging (v1.1) of groups and memberships • Privileges • ADMIN, UPDATE, READ, VIEW, OPTIN, OPTOUT • Group attribute set can be site-extended

28. Naming Stems • Groups are created with naming stems • Limits the authority to create and name groups • Support distinct activities with own authority • Naming stems can be arranged hierarchically eg, uc, uc:nsit, uc:nsit:labs • Privileges • STEM • Create subordinate naming stems • Assign privs for this naming stem • CREATE – create groups with this naming stem

29. Composite Groups • Membership is defined by composing the memberships of 2 other groups • A = B U C union • A = B ∩ C intersection • A = B – C relative complement • Common use – “tweak” existing groups • Whitelist or blacklist factored in to another group

30. Example: Computer Cluster Access categories of barred students (auto) time dependent student categories (auto) Allow access if in (nsit:labs:eligible – nsit:labs:barred) nsit:labs:eligible (manual) nsit:labs:barred (manual) nsit:labs:whitelist (manual) nsit:labs:blacklist (manual) uc:faculty (auto) uc:staff (auto) categories of entitled students (auto)

31. Systems Integration • API • XML Import/Export Tool • Snapshots Groups Registry, including naming stems and privileges • A single group • All subordinate to a specified naming stem • All matching a search condition • Entire Registry

32. Signet Overview • Analysts define privileges in functional terms and specify associated system-level permissions • Signet presents this functional view in a Web UI where users assign privileges & delegate authority across all areas in which they have authority • Signet internally maps assigned privileges into system-specific terms needed by applications • Privileges are exported, transformed, & provisioned into applications and infrastructure services • Signet provides automated lifecycle controls

33. Functional view Subsystems Categories Functions Scope, Limits Prerequisites & Conditions System view Permissions Subject Action Resource Privileges Building Blocks

34. Functional View Subsystems contain… Limits • Qualifiers, constraints for a privilege • Scope • Organizational hierarchy governing distributed delegation • Functions The things a person can do; what they are getting privileges for Categories • Provide useful arrangement of functions within a subsystem; for reporting, ease of use

35. Functional View Add/Drop students Course Support Student Admin Which term Schedule Classes Which campus Process Applicants For school… Financial Aid Award Scholarships From Fund… Manage Accounts For fund… Patient Records Protocol A Clinical Trial Read/Write Materials Control Qty/day Manage Grant Admin $ constraints Lab Access Hours Categories Subsystems Functions Limits organizing actions

36. Systems View • Permissions • Atomic units of control that map to specific access rules in systems • Includes limits that must be evaluated when interpreting permissions Resources • The target of a specific privilege; things that have access rules to control their use

37. Functional View  Permissions Calendar Student Admin reserve_time view_schedules Add/Drop students Course Support Course Schedule Classes update_course_data Facilities reserve_room Process Applicants Financial Aid Financial Award Scholarships view_fund_data update_fund_data Manage Accounts Student student_records categories functions applicant_data Functional View Resources/Permissions

38. Systems Integration • API • Permissions document • XML representation of privileges for an individual or group • Will be compatible with XACML

39. Privileges Lifecycle Conditions • Provides automatic revocation of privileges • Date controls -- from date, until date • Will be based on person’s status, affiliation, etc. e.g., as long as person is at Stanford Prerequisites • Pre-conditions that must be met to activate privileges e.g., training

40. Other features Assignments can be • To an individual • To a Group With/without ability to further delegate • Distributed delegation using organizational hierarchy • Records “chain of command” Proxy assignment • Temporary granting of one’s privilege to another

41. Privilege Elements by Example Lifecycle Privilege

42. Generic Integration Architecture

43. Further Integration Tasks • Automated loading of groups & privileges • Authentication service • Application-specific integration capabilities • Site-specific LDAP schema • Authoring/maintaining subsystem metadata • Solution requisites • Which groups should be made available to the calendaring, email list, & wiki systems? • The Boss may need an automatic grant of a Signet privilege to manage his wiki space • Implementing service policies – Grouper naming stems & privileges or Signet privileges

44. Subject API:Site IAM Integration Requirements • Subject - a person, group, application, or other type of object whose identity is managed by your IAM system • Abstract the underlying technology and data model from a relying application • Enable identifier namespaces to be selected to match application needs • Username vs. opaque registryID vs. … • Scenarios • Map authenticated user to internal security principal • Reference/search objects within application

45. Subject API:Integration with Site’s IAM

46. Source Adapter Configuration • Name the source & specify connection details • Name the type or types of subjects residing there • Identify attributes/columns distinguished as “subjectID”, “name” and “description” • Specify back-end-specific searches for each type and each search method • Select • Search by identifier • Search • Sites should make consistent assignment of source and type names across all source adapter instances • They are persisted by Subject API clients

47. Signet & Grouper Roadmaps • Now available • Grouper v0.9. UI & API source release • Signet 1.0. UI, binary release • Subject API v0.1b • Signet Roadmap • v1.1, ? 2006 – full API source release • v1.2, ? 2006, – rules processor • Grouper Roadmap • v1.0, May 2006 – group math • v1.1, ? 2006 – group & membership aging • Subject API • v1.0, ? 2006 – minor changes, updates to reference implementations

48. Resources & Participation • Grouper • team: University of Chicago & University of Bristol • http://grouper.internet2.edu • Signet • team: Stanford University • http://signet.internet2.edu • Internet2 Middleware Initiative • http://middleware.internet2.edu/ • Documents, software, cvs • Details for subscribing to mailing lists • Conference call agendas & dialing instructions