Stanford University Authority Registry December 12, 2001 Stanford University Lynn McRae

1. Stanford University Authority Registry December 12, 2001 Stanford University Lynn McRae Stanford University

2. 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 Stanford University

3. 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 Stanford University

4. 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 Stanford University

5. 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 Stanford University

6. 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 Stanford University

7. 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. Stanford University

8. Authority Model: Concepts and Components Stanford University

9. 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 Stanford University

10. 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. Stanford University

11. 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 Stanford University

12. 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 Stanford University

13. 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) Stanford University

14. 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 Stanford University

15. AuthorityManager Stanford University

16. Authority Manager Stanford University

17. Authority Manager Stanford University

18. 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 Stanford University

19. Authority Model: XML document <?xml version=“1.0” encoding=“UTF-8” ?> <DOCTYPE Privileges> <Privileges> <principal roid=“person/64ec5fa6e7701d1830c246000baa77” sunetid=“jdoe” univid=“09273311”>Doe, Jane</principal> <domain id=“student_admissions”> <privilege entitlement=“student_admissions:manage_applicant” <scope roid=“organization/000cf6f0003ede39a22108ab400b0baa77” systemid=“gsb” orgid=“UAAA”>Graduate School of Business </scope> <limit id=“admit_center”> <value type=“text” description=“Sloan Program”>ASLO</value> </limit> Stanford University

20. 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 Stanford University

21. 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? Stanford University

22. 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 Stanford University

23. 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 Stanford University

24. 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 Stanford University

25. 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 Stanford University