Privilege Management: the Big Picture nmi-edit Privilege Management: the Big Picture 2004 Advanced CAMP Authority Architectures Workshop Boulder, June 30, 2004 Lynn McRae Stanford University lmcrae@stanford.edu Copyright Lynn McRae, 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. 12/1/2018

The Path to Privilege Management Local accounts, individuals mapped to permissions list Local accounts mapped to local groups mapped to permissions list Integration with external information -- affiliations, status, etc. Integration with institutional group/roles Centralized privilege management Taxonomy of methods for managing security 12/1/2018

PM -- Local accounts Individuals mapped to permissions list No policy control and tracking Historically weak life-cycle controls Does not support cross-system privileges Magic elf -- that person who you write to to open a new account, you email to update privileges, where help tickets get routed to to fix access. They work through product panels, or edit acls directly, a human element that can be prone to error. Supports an exception-driven process, you lose track of WHY a person has a permission -- was it because of a role or a special request, how long should it last…etc 12/1/2018

PM - Local accounts & groups Local privileges grouped for categories of access If done well can reflect roles or policy But interpretation of policy across many systems Still not cross-system 12/1/2018

PM - External data Opportunity to automate lifecycle “User” is for session/preferences, not control A start at roles-based authorization Rules for mapping relationships to permissions still implemented across systems 12/1/2018

PM -- Institutional groups & roles Mapping people to groups is implemented once Consistency from common group definitions Improved roles-based authorization Applications still have local mapping to privileges 12/1/2018

PM - Central Management Single implementation mapping person to privileges, or person to group to privileges Independent from specific systems & technologies Allows privileges to be shared across systems Central rules can be complex or simple, but done once; central priv management can operate against individuals or against the groups 12/1/2018

Role- vs Privilege-based AuthZ Both approaches are viable, complementary Roles (cf. eduPersonIsMemberOf) Inter-realm, specific privileges vary in different contexts e.g. Instructor can submit grades at one site, readonly at another Eligibilility (can have) instead of authorization (can do) e.g. Faculty/Staff /Students get free email from specific provider Privileges (cf. eduPersonEntitlement) Permissions should be the same across service providers Service providers do not need to know rules or reason behind authorization e.g. Building access regardless of why -- has office in building, taking class in building, authorized by building manager 12/1/2018

Central Privilege Management A system independent source for defining and administering privilege data Central repository simplifies policy management and tracking Consistent application of rules across systems Levels of institutional commitment NOT an authorization service… A source of data for an authorization service Integrates with local system security Integrates with authorization mechanisms What is an authorization service? 12/1/2018

What is Signet? A Privilege Management System & toolkit Software to define an organization’s privileges Software to manage privilege information A web user interface for distributed assigning and viewing privilege information Components/APIs for integrating with other systems NSF funded Internet2 /MACE project Part of AuthZ core middleware initiative 12/1/2018

Demo - Stanford Authority Manager home page 12/1/2018

Demo - Stanford Authority Manager home page 12/1/2018

Demo - Stanford Authority Manager - User view 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager -Granting 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager - Granting 12/1/2018

Demo - Stanford Authority Manager - User view 12/1/2018

Privileges building blocks 12/1/2018

Privileges building blocks Business view Subsystems Categories Functions System view Entitlements Shared Scope, Limits Pre-requisites, Conditions 12/1/2018

Subsystems Highest unit of organization, defines domains of ownership and responsibility One built-in subsystem to manage other authority subsystems Reflect real world organizational boundaries and areas of responsibility Can be large or small 12/1/2018

Categories Group privileges into topics within a subsystem Organize data logically for UI and reports Some control features, e.g., choose one vs choose many 12/1/2018

Function/Tasks/Entitlements 12/1/2018 financial_SQLGL:DelphiEnt_EN_GL_Inquiry

Scope Places privileges in a hierarchical context Distributed delegation via a chain of authority “you can only give what you have” Independent of personnel hierarchy 12/1/2018

Limits One or more qualifiers for a privilege Choice types: Numeric, ranges Single/multiple choice User input values, edited against domain of values Scoped limits -- things “owned” by items in a hierarchy Knows “less” or “fewer” for delegation 12/1/2018

Entitlement integration 12/1/2018

Assignment features Prerequisites (auto-activation) Conditions (auto-revocation) Having vs delegating authority 12/1/2018

Assignment features Assigning privileges to groups XML output Groups may represent roles But Role management per se is a future concern XML output Union of privileges, plus Privileges that you have as an individual Privileges you have via proxy Privileges via group membership 12/1/2018

Other features Designated drivers Notification Audit history Authority granting proxy Acting proxy Notification Audit history 12/1/2018

Assignment example By authority of the Dean grantor as soon as you are principal investigator role (group) and have completed training prerequisite you can approve purchases function in the School of Medicine scope for your research project up to $100,000 limits until January 1, 2006 condition 12/1/2018

For more information… The project web site: http://middleware.internet2.edu/signet/ Email list: signet@internet2.edu Magic elves drawing from http://intranet.hackney-lea.org.uk/highwire/srb intranet/fairy tales/fairytales/fairytales menu.html 12/1/2018