Stanford University Authority Registry December 12 2001 Stanford

Stanford University Authority Registry December 12, 2001 Stanford University Lynn Mc. Rae December 2001 Internet 2 Virtual Briefing 1 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 Internet 2 Virtual Briefing 2 Stanford University

Organization’s Background • Computing Environment – – – – – Single campus, 16000 students, 8500 faculty/staff 600+ active subnets, 64000+ 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 email (POP and IMAP) Enterprise directories for “whois” and infrastructure Schizophrenic - administrative vs academic computing December 2001 Internet 2 Virtual Briefing 3 Stanford University

Organization’s Background • Key project or systems – Major administrative systems replacement. • People. Soft student system, Fall 2001 • People. Soft 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 Internet 2 Virtual Briefing 4 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 Internet 2 Virtual Briefing 5 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 Internet 2 Virtual Briefing 6 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 Internet 2 Virtual Briefing 7 Stanford University

Authority Model: Concepts and Components December 2001 Internet 2 Virtual Briefing 8 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 Internet 2 Virtual Briefing 9 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 Internet 2 Virtual Briefing 10 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 Internet 2 Virtual Briefing 11 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 Internet 2 Virtual Briefing 12 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 Internet 2 Virtual Briefing 13 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 Internet 2 Virtual Briefing 14 Stanford University

Authority Manager December 2001 Internet 2 Virtual Briefing 15 Stanford University

Authority Manager December 2001 Internet 2 Virtual Briefing 16 Stanford University

Authority Manager December 2001 Internet 2 Virtual Briefing 17 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 Internet 2 Virtual Briefing 18 Stanford University

Authority Model: XML document <? xml version=“ 1. 0” encoding=“UTF-8” ? > <DOCTYPE Privileges> <principal roid=“person/64 ec 5 fa 6 e 7701 d 1830 c 246000 baa 77” sunetid=“jdoe” univid=“ 09273311”>Doe, Jane</principal> <domain id=“student_admissions”> <privilege entitlement=“student_admissions: manage_applicant” <scope roid=“organization/000 cf 6 f 0003 ede 39 a 22108 ab 400 b 0 baa 77” systemid=“gsb” orgid=“UAAA”>Graduate School of Business </scope> <limit id=“admit_center”> <value type=“text” description=“Sloan Program”>ASLO</value> </limit> December 2001 Internet 2 Virtual Briefing 19 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 Internet 2 Virtual Briefing 20 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 Internet 2 Virtual Briefing 21 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 Internet 2 Virtual Briefing 22 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 Internet 2 Virtual Briefing 23 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 email to Board of Trustees, print list of Board of Trustees in the directory December 2001 Internet 2 Virtual Briefing 24 Stanford University

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