Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005

1. Stanford Authority ManagerPrivilege management use caseIntegration CAMPDenver, June 27, 2005 Lynn McRae Stanford University lmcrae@stanford.edu

2. Stanford 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 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 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 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 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 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. Prerequisitescontrol auto-activation 2,950 assignments are “pending” Most: nightly feed from LMS (STARS - Stanford Training and Registration System) Some: direct workgroup maintenance Prerequisites • 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. Conditions • Conditionscontrol 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. Security • 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 page

12. Authority Manager - Home page

13. Authority Manager - Home page

14. Designated 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 page

16. Help 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. Janet King Janet King Janet King Janet King Authority Manager - Person View

18. Authority Manager - Person View

19. Integration Challenges • 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 No user serviceable parts Warranty void if opened

20. Integration 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 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. Reporting • 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 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 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. Successes • 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

26. Fini Questions… Contact: Lynn McRae, lmcrae@stanford.edu