Lynn McRae

Stanford University

lmcrae@stanford.edu

Lynn McRae

Stanford University

lmcrae@stanford.edu

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

26

FiniFini

Questions…

Contact:

Lynn McRae, lmcrae@stanford.edu