December 2001 Internet2 Virtual Briefing - 1 -Stanford University Authority Registry December 12, 2001 Stanford University Lynn McRae

December 2001 Internet2 Virtual Briefing - 2 -Stanford University Organization’s Background Presenters role in organization –Technical Lead of 5 person development team for infrastructure/integration development –Project manager for interrelated Registry and Directory based projects –Focus on information integration via Enterprise Registries

December 2001 Internet2 Virtual Briefing - 3 -Stanford University Organization’s Background Computing Environment –Single campus, students, 8500 faculty/staff –600+ active subnets, registered nodes –Sun/Solaris servers; diversity of desktop platforms –Campus-wide authentication via Kerberos –Single campus-wide identifier namespace (SUNet Ids) –Enterprise db: Oracle (admin), Sybase (infrastructure) –Campus-wide file system (AFS) –Enterprise (POP and IMAP) –Enterprise directories for “whois” and infrastructure –Schizophrenic - administrative vs academic computing

December 2001 Internet2 Virtual Briefing - 4 -Stanford University Organization’s Background Key project or systems –Major administrative systems replacement. PeopleSoft student system, Fall 2001 PeopleSoft HR system, Winter 2002 Oracle Financials, Fall, 2002 –Authority Registry –Organization, Account, Course, Facilities Registry –Portal, Enterprise Calendar –Windows 2000 –New Faculty/Academic mission

December 2001 Internet2 Virtual Briefing - 5 -Stanford University Organization’s Background Key integration issues –Data integration Person (ongoing) Organization –Authority/security integration –Namespace, single-signon, other systems/users –UI integration for self-service applications

December 2001 Internet2 Virtual Briefing - 6 -Stanford University Authority Model: Objectives and Scope Simplification –Authority “at a glance” –Designed from the business, not system perspective Consistency –Single implementation of policy, common data & rules –Different applications and services using the same Authority information the same way Automated life-cycle management –Automatic activation/inactivation –Notification –Audit, history

December 2001 Internet2 Virtual Briefing - 7 -Stanford University Authority Model: Concepts and Components An Authority Registry -- a managed repository of authority assignments -- not an Authority System. Authority is defined first in business terms, without reference to any specific system or application. The Authority Registry separates user visible portions of authority management, expressed in business terms, from internal system components expressed in technical terms. Applications must read and translate authority information into local terms.

December 2001 Internet2 Virtual Briefing - 8 -Stanford University Authority Model: Concepts and Components

December 2001 Internet2 Virtual Briefing - 9 -Stanford University Authority Model: The Details… Functions –The basic unit of Business work. A person’s job will consist of one or more Functions. –Authority assignments are at the Function level. –Functions consist of one or more Tasks. Tasks –A discrete unit of work, typically a piece of what is needed to accomplish a function. –Represents a set of privileges that must be be set together. –Are reusable

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: The Details… Entitlements –Atomic unit of authority control. –An abstraction of system specific privileges, but not in any system’s specific language. –What applications read to set their internal security.

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: More Details… Scope –Something to which authority is bound, such as a department or budget. –Department definitions and hierarchy are critical –Distribution of authority management –“Smart parms” Conditions –Provides life-cycle management Bound to scope, e.g., while at Stanford; as long as in current department Or date based, e.g., from 12/01/01 until 12/31/01

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: More Details… Prerequisites –Like conditions, but comes before authority can be enabled Limits –Constraints to the use of authority, e.g., dollar limits –Special built-in limits: read-only, self-only, not-self Delegation

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: More Details… Example: –As soon as you take the training (pre-requisite) –you can manage financial aid (function) –for undergraduates (limit, smart parm) –in the School of Engineering (scope) –as long as you are in the Dean’s office (condition)

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: The Details… Implementation –Web-based UI for Authority assignment and lookup –Integrated with Stanford.You (self-serve app) so individuals can see their authority –Integrated with Organization manager app so departments can review all authority at their level

December 2001 Internet2 Virtual Briefing Stanford University Authority Manager

December 2001 Internet2 Virtual Briefing Stanford University Authority Manager

December 2001 Internet2 Virtual Briefing Stanford University Authority Manager

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: Integration… Integration with other systems –The combination of authority, context, limits, etc. is a net set of “privileges’ – XML Privileges document –Applications access Document Server via https –Some privileges reflected as privgroup attribute in directory entry for individuals –Other directory representations planned, but not soon

December 2001 Internet2 Virtual Briefing Stanford University Authority Model: XML document <principal roid=“person/64ec5fa6e7701d1830c246000baa77” sunetid=“jdoe” univid=“ ”>Doe, Jane <privilege entitlement=“student_admissions:manage_applicant” <scope roid=“organization/000cf6f0003ede39a22108ab400b0baa77” systemid=“gsb” orgid=“UAAA”>Graduate School of Business ASLO

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Roles? Despite other successes, “Roles” themselves have yet to be implemented –Design is for Organizational roles –New HR system possibilities for institutional roles; debate over how many, how broadly applicable, whether tied to jobs or billets, etc. –Wide diversity in what constitutes a given role; schools vs big departments vs small departments –Fear factor

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Roles? Possibilities –De facto roles: “granting” power for heads of organizations, instructors, Principal Investigators –System roles: system owner, central office –Local, Departmental roles –Acting “in role” not planned (not supported across applications) –Nesting of roles?

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Roles? Do we need roles? –Functions offer a level of roll-up that have been called “mini roles” –Partly because of business simplification –Student authority: Administer Financial Aid Manage Admissions Manage Student Records Manage Student Financials Manage Student Records

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Roles? –Human Resources authority: HR, Benefits –Allocate Labor Costs –Manage HR Records –Manage HR Positions –Manage Faculty Status Payroll –Manage Payroll –Process Payroll Manage Leave Information Manage Timesheet Information

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Roles? Do we need roles? (cont) –Features that de-emphasize roles, e.g., copying or transferring authority –Workgroups offer “poor man’s roles” –Plan to offer user/department defined roles In the context of the Organization Manager Life-cycle management parallels authority Allows re-use of roles outside of authority, e.g., authorize Board of Trustees, send to Board of Trustees, print list of Board of Trustees in the directory

December 2001 Internet2 Virtual Briefing Stanford University Authority Model – Greatest Challenges Business -- Cultural shift to new paradigm Allocation of sufficient and/or proper resources in project plans Aggressive application deployment schedules focused on core function, not integration Sense of partnership beyond design phase (both ways) Higher investment costs for participation in lieu of local solutions Shared entitlements Technically -- Integration with vendor/packaged systems New technologies, still fragile Vendor integration support limited, proprietary or not applicable Package security cannot necessarily support expressed authority