Stanford authority manager privilege management use case integration camp denver june 27 2005
Download
1 / 26

Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005 - PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on

Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005. Lynn McRae Stanford University [email protected] Stanford Authority Manager. Initial production, November 2001 Created in conjunction with ERP migration from mainframe

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Stanford Authority Manager Privilege management use case Integration CAMP Denver, June 27, 2005' - baakir


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Stanford authority manager privilege management use case integration camp denver june 27 2005

Stanford Authority ManagerPrivilege management use caseIntegration CAMPDenver, June 27, 2005

Lynn McRae

Stanford University

[email protected]


Stanford authority manager
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


Stanford authority goals
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.


Stanford authority architecture
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”


Stanford authority architecture1
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.


Authority manager assignments
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


Authority manager assignments1
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


Prerequisites

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


Conditions
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”


Security
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





Designated drivers
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



Help and training
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


Authority manager person view

Janet King

Janet King

Janet King

Janet King

Authority Manager - Person View



Integration challenges
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


Integration challenges1
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


Integration challenges2
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


Reporting
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


Ui challenges
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


Functional needs
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


Successes
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


Fini

Questions…

Contact:

Lynn McRae, [email protected]


ad