1 / 26

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

Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005. Lynn McRae Stanford University lmcrae@stanford.edu. Stanford Authority Manager. Initial production, November 2001 Created in conjunction with ERP migration from mainframe

sonya-stephenson
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related