Stanford University Authority Registry December 12 2001 Stanford

  • Slides: 25
Download presentation
Stanford University Authority Registry December 12, 2001 Stanford University Lynn Mc. Rae December 2001

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

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,

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.

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

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

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 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: Concepts and Components December 2001 Internet 2 Virtual Briefing 8 Stanford University

Authority Model: The Details… • Functions – The basic unit of Business work. A

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

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

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

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

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

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

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

Authority Model: Integration… • Integration with other systems – The combination of authority, context,

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>

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

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

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

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

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

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

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