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

December 2001 Internet2 Virtual Briefing - 1 - Stanford University

Stanford University

Authority Registry

December 12, 2001

Stanford University

Lynn McRae


Organization’s BackgroundOrganization’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


Organization’s BackgroundOrganization’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



• 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



• Key integration issues– Data integration

• Person (ongoing)

• Organization

– Authority/security integration

– Namespace, single-signon, other systems/users

– UI integration for self-service applications


Authority Model:Authority Model: Objectives and Scope 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


Authority Model:Authority Model: Concepts and Components 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.


Authority Model:Authority Model: Concepts and Components Concepts and Components


Authority Model: The Details…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



• 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.


Authority Model: More Details…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



• 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



• 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)



• 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


AuthorityAuthority ManagerManager


Authority ManagerAuthority Manager


Authority ManagerAuthority Manager


Authority Model: Integration…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


Authority Model: XML documentAuthority 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>


Authority Model – Roles?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



• 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?



• 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



– 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



• 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


Authority Model – Greatest ChallengesAuthority 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

Documents

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