Lynn McRae
Stanford University
Lynn McRae
Stanford University
Stanford Authority ManagerPrivilege management use case
Integration CAMPDenver, June 27, 2005
Stanford Authority ManagerPrivilege management use case
Integration CAMPDenver, June 27, 2005
2
Stanford Authority ManagerStanford Authority Manager
• Initial production, November 2001
• Created in conjunction with ERP migration from mainframe• Student Administration (PeopleSoft/SA)• Sept 2001
• Human Resources (PeopleSoft/HR)• Sept 2002
• Oracle Financials• Sept 2004
3
Stanford Authority GoalsStanford Authority Goals
• Simplify authority policy, management and interpretation.
• Manage and summarize the privileges of an individual in one place.
• Support consistent application of authority across systems via the infrastructure.
• Provide automatic revocation of authority based on affiliation changes.
• Evolve role-based authority -- managing privileges based on job function.
4
Stanford Authority ArchitectureStanford Authority Architecture
• Central Authority Management• Common user interface.• based on business functions and language, not
system-specific or in technical terms
• Rich privileges -- e.g., scope, direct qualifiers, indirect qualifiers
• Supports a model of distributed Authority management.• Integrated with Organizational Registry• Records “chain of delegation”
5
Stanford Authority ArchitectureStanford Authority Architecture
• Central Authority Management• A repository of authority assignments and
resulting privilege information.• Does not replace the security systems in
each local system.• Requires integration/synchronization of data
between Authority system and local systems.• Features to facilitate mapping of user
assignments to target systems.
6
Authority Manager AssignmentsAuthority Manager Assignments
• 45,000+ active assignments (70k to date)• 32,000+ financial• 5,500+ hr• 3,500+ student• 4,000+ Enterprise Reporting• 58 Research Administration (conflict-of-interest)• 4 Space Management (new)
• 144 are “authority authority” assignments• For “granting proxy” within Authority Manager
Statistics gathered week of June 20-25, 2005
7
Authority Manager AssignmentsAuthority Manager Assignments
• 381 current grantors (2.6% of ~14,000 faculty/staff)
• 329 financial• 45 hr• 116 student
• 5,106 current grantees (36% of faculty/staff)
• 2,899 financial• 795 hr• 1,183 student
• 897 grantees (18%) can delegate to others
8
PrerequisitesPrerequisites
• Prerequisites control auto-activation
• 2,950 assignments are “pending”
• Most: nightly feed from LMS (STARS - Stanford Training and Registration System)
• Some: direct workgroup maintenance
•Manage HR Records Training•Alcohol Approver•Sign Confidentiality Statement•Cost Policy Training•DPA•iBudget Training•Labor Distribution Training
•Labor Distribution Adjustments Training•GFS Policy and Entry Training•GFS Read Only Access Training•Student Records Dept Course Setup•Student Admin Basics Training•FERPA GLB, Student Financial Acct Training
9
ConditionsConditions
• Conditions control auto-revocation• 462 assignments have expiration date• 1.1% of 42,000 active assignments
• All others have “While at Stanford”• Based on “stanford administrative” -- faculty,
staff (including casual/temps) and sponsored affiliates
• Mostly great, but not precise enough -- need “while in department”
10
SecuritySecurity
• Granting authority governed by two principles• You can only give what you have, or less• Permission use or to give to others is separate
and explicit
• Stanford Authority Manager is open to the “Stanford administrative” community
• Any user can see all privileges for any other user
11
Authority Manager - Home pageAuthority Manager - Home page
12
Authority Manager - Home pageAuthority Manager - Home page
13
Authority Manager - Home pageAuthority Manager - Home page
14
Designated driversDesignated drivers
• Granting proxy• Acting in Authority Manager for someone else
who has Authority• Can “grant only”; does not actually have
privileges• Cultural necessity
• Acting approver• Assumes privileges temporarily
15
Authority Manager - Home pageAuthority Manager - Home page
16
Help and TrainingHelp and Training
• Core system owned by Stanford IT (ITSS)• General use/availability/problem reports
through central Help Desk• Tier 1 help, else direct user to central office or IT staff.
• Web based training• IT developed module for basic system commands and
concepts• Subsystem owners responsible for training module in
their own realm• Online Tutorial available through the UI
17
Authority Manager - Person ViewAuthority Manager - Person View
Janet King
Janet King
Janet King
Janet King
18
Authority Manager - Person ViewAuthority Manager - Person View
19
• PeopleSoft and Oracle do not have security APIs
• Custom development to process “privileges” XML document into local system
• Inadequate resource planning for the scope of integration work
• Skill set issues
• Has led to more centralized support for integration
Integration ChallengesIntegration Challenges
No user serviceable partsWarranty void if opened
20
Integration ChallengesIntegration Challenges
• PeopleSoft still uses manual integration• Nightly email/printed report• Staff job to transfer data into PeopleSoft
security panels• Being automated this summer
• Audits• Required to establish trust in Authority
Manager assertions• Non-trivial independent effort• Effort is ongoing
21
Integration ChallengesIntegration Challenges
• Authority/business system functional gaps• Oracle Financials, more than 1 active approver• Oracle Financials, workflow referrals up• PeopleSoft: cross associations (false positives)
• Bootstrap grantor issues • “real” authorization chain• schools vs central office model• bulk loading at initial conversion, no recorded
chain of authorization
22
ReportingReporting
• Online views• Good for person details• Weak for organization level details
• Lack of independent reporting• Priority for new development• Controls for reporting down a hierarchy
• Upcoming work to integrate with ReportMart
23
UI ChallengesUI Challenges
• Style of business language• Nouns/verbs, roles/action, non-system-specific
• Perceived complexity of wizard interactions for repetitive tasks• Ameliorated by some wrap-around controls
• Performance/scalability problems in Web app, esp. for users with a lot of authority
24
Functional needsFunctional needs
• Granting to Groups or Roles
• Transfer of authority from old to new person
• Revoke all
• Bulk grantor updates
• Lack of administrative interface• Supported centrally by IT staff• Changes in metadata complex and confusing
• Option to limit granting to only one level
25
SuccessesSuccesses
• Distributed delegation model
• Auto-activation and revocation
• Near realtime integration• Stanford events service
• Consistency of UI across domains
• Re-use across systems (report mart)
• Stanford model adopted for I2/NMI Signet Privilege Management software