1. 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
Copyright Lynn McRae, 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

2. 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

3. 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 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

4. 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

5. 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

6. 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

7. 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

8. 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 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

9. 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

10. 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

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

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

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

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

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

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

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

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

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

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

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

22. Privileges building blocks
12/1/2018

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

24. 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

25. 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

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

27. 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

28. 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

29. Entitlement integration
12/1/2018

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

31. 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

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

33. 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

34. For more information…
The project web site:
list:
Magic elves drawing from intranet/fairy tales/fairytales/fairytales menu.html
12/1/2018