1. Lynn McRae Stanford University lmcrae@stanford.edu Lynn McRae Stanford University lmcrae@stanford.edu Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005

2. 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. 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. 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. 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. 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. 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. 8 Prerequisites 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. 9 Conditions 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. 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. 11 Authority Manager - Home page

12. 12 Authority Manager - Home page

13. 13 Authority Manager - Home page

14. 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. 15 Authority Manager - Home page

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

18. 18 Authority Manager - Person View

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

20. 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. 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. 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. 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. 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. 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. 26 Fini Questions… Contact: Lynn McRae, lmcrae@stanford.edu