Moving Beyond Implementation: Authorization Tom Barton, University of Chicago

Copyright Tom Barton 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author. 17 November 2004 IdM CAMP 2

Outline Why have common infrastructure to manage authorization? Case study in group management: U Chicago’s “USITE” computer labs & a tour of Grouper Privilege management with Signet How do you know when to use groups and when to use privileges? 17 November 2004 IdM CAMP 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 options for unifying authentication service with the hospital system.  Gasp as you gradually realize that current access controls are too often based solely on ability to authenticate. 17 November 2004 IdM CAMP 4

Scenario – General Services General services: the need to serve more loosely affiliated constituencies breaks the simple “log in and get it all” model Need granular access to services 17 November 2004 IdM CAMP 5

Scenario – Administrative Services If you don’t have a comprehensive and vendor-integrated ERP, you’ve got a set of systems each with their own security management The more standalone security management domains you’ve got the harder to implement authority in accord with organizational policy Setup new user Change of status Termination 17 November 2004 IdM CAMP 6

Scenario – IdMS 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. Provide local tech support Manage access to local resources Assign password policy class 17 November 2004 IdM CAMP 7

Scenario - Portal The portal through which you’d like to provide services needs to know enough about each person’s roles to present them with customized views. Major affiliations Activity-specific roles 17 November 2004 IdM CAMP 8

Scenario – Messaging & Collaboration You want to make it easy for people to share documents among collaborators. Poor options: Send documents by email Share them with the world on a web site Otherwise, it’s 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, it’d be even nicer if that list wasn’t tied directly to each collaborative or messaging system. 17 November 2004 IdM CAMP 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 Maybe use an access management system instead? All workflows rely on roles, i.e., authority 17 November 2004 IdM CAMP 10

Scenario – Mature NOS or IFS or … Your Active Directory or Novell or AFS or DCE or … deployment is mature and has a valuable set of groups. Now they’re needed elsewhere too. Develop point to point flows or a common infrastructure? 17 November 2004 IdM CAMP 11

Authority Management “Authority” needs to be managed Many scenarios Many terms: access, security, roles, permissions, privileges, lists, groups, affiliations The architecture for managing authorization information can be siloed or integrated Use native means for each application … or … Externalize the management system and integrate applications with it 17 November 2004 IdM CAMP 12

Elements of an Integrated Authority 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 17 November 2004 IdM CAMP 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 services Increase overall impact of the above by increasing the number of integrated services due to the middleware meeting more requirements, ie, authZ in addition to authN and management of basic identifiers. 17 November 2004 IdM CAMP 14

U Chicago’s 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 Chicago’s Networking Services & Information Technologies (NSIT) established the Identity Management Working Group to solve this type of problem You’ll see “nsit” and “usite” in names of things to follow 17 November 2004 IdM CAMP 15

USITE access policy Students Current faculty & staff are entitled 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 November 2004 IdM CAMP 16

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 17 November 2004 IdM CAMP 17

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) uc:faculty (auto) uc:staff (auto) categories of barred students (auto) categories of entitled students (auto) time dependent student categories (auto) 17 November 2004 IdM CAMP 18

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 17 November 2004 IdM CAMP 19

Data flow & Grouper’s role in USITE access SIS Loaders Grouper API lab HR Person registry LDAP Grouper UI API Group registry Dir. Learning Environments uid: jdoe ucAffiliation: … isMemberOf: … Grouper API Lab Managers Student staff 17 November 2004 IdM CAMP 20

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 17 November 2004 IdM CAMP 21

Group namespaces Groups are created within 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 Namespaces can be arranged hierarchically, if desired 17 November 2004 IdM CAMP 22

Naming Examples NSIT namespace nsit Subordinate USITE namespace nsit:usite Group within that namespace nsit:usite:admin_admit The namespace delimiter can be configured for different effect /nsit/usite/admin_admit 17 November 2004 IdM CAMP 23

Grouper privileges Access privileges Naming privileges Who has what access (read, write) to a group’s 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 don’t want to use Grouper’s built-in privilege management Subgroups, compound groups, and aging can be used to manage privileges with built-in capability 17 November 2004 IdM CAMP 24

Access privileges VIEW controls to whom a group is visible or hidden READ information, especially membership, about a group UPDATE membership 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 17 November 2004 IdM CAMP 25

Naming privileges CREATE a group in a given namespace The creator is automatically given ADMIN priv STEM privilege in a given namespace enables: Assignment of CREATE and STEM privileges for the namespace Creation of subordinate namespaces The creator is automatically given STEM priv 17 November 2004 IdM CAMP 26

Three ways to distribute group management Create a group and assign someone UPDATE privilege to it Manage the group’s membership Create a group and assign someone ADMIN privilege to it Manage who manages the group’s 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 17 November 2004 IdM CAMP 27

Granular USITE Access with Grouper Make an “nsit:usite” namespace in the Group Registry Grant STEM privilege for “nsit:usite” to the Director of Learning Environments Create those manually managed nsit:usite groups Automatically maintain student, faculty, & staff related groups in other namespaces as part of IdMS operation Assign privileges to all of these groups 17 November 2004 IdM CAMP 28

USITE group access privileges (unqualified names in nsit:usite namespace) usite_eligible A:dir_learning_env V,R:all usite_barred A:dir_learning_env V,R:all admin_admit U:usite_manage V,R:usite_view admin_deny U:usite_manage V,R:usite_view uc:faculty V,R:all uc:staff V,R:all categories of barred students V:all V:all V:all categories of entitled students V:all V:all time dependent student categories V:all V:all V:all V:all 17 November 2004 IdM CAMP 29

USITE group management privileges (unqualified names in nsit:usite namespace) 17 November 2004 IdM CAMP 30

Signet 11/16/2018 31

Nutshell Description Analysts write XML descriptions of “business views” of privileges 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 17 November 2004 IdM CAMP 32

Signet Subsystems Define domains of ownership and responsibility Reflect real world boundaries Can be large or small Financial system Student system HR system Network address plan management Network access management Research administration Clinical resources IdMS UI (Person Registry) Signet (Authority Registry) Grouper (Group Registry) 11/16/2018 33

Authority elements by example By authority of the Dean grantor principal investigators grantee (group) who have completed training prerequisite can approve purchases function in the School of Medicine scope for research projects up to $100,000 limits until January 1, 2006 condition 17 November 2004 IdM CAMP 34

Privileges building blocks Business view Subsystems Categories Functions Scope Limits Prerequisites Conditions System view Permissions Assignment to Individual Group Proxy assignment 11/16/2018 35

Business View  System Permissions 11/16/2018 36

Provisioning Permissions into Systems 11/16/2018 37

Provisioning Permissions into Infrastructure 11/16/2018 38

Signet components 11/16/2018 Yellow = institution provided 39

Signet & Grouper Availability NSF Middleware Initiative’s 6th release of componentry early this December will include Initial release of Grouper API, v0.5. 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 (v0.6) Production ready release of Signet anticipated middle of 2005 17 November 2004 IdM CAMP 40

Scenarios revisited: Is it groups or privileges that are needed? General services Administrative services IdM adoption Portal Messaging & collaboration Workflow Mature NOS, IFS, … GROUPS, privs groups, PRIVS Groups, Privs Groups, PRIVS 17 November 2004 IdM CAMP 41

Resources http://middleware.internet2.edu/dir/groups http://middleware.internet2.edu/signet hazelton@doit.wisc.edu tbarton@uchicago.edu 17 November 2004 IdM CAMP 42