A'Vandenberg

1
Directory and Person RegistryImplementation
Details

• Art Vandenberg
• Director, Advanced Campus Services
• Information Systems Technology
• Georgia State University
• Avandenberg_at_gsu.edu

2
Doing of New Things

• What is science? a special method of finding
  things out the body of knowledge It may also
  mean the new things you can do when you have
  found something out, or the actual doing of new
  things. This last field is usually called
  technology
• Richard P. Feynman, The Meaning of It All
  Thoughts of a Citizen Scientist, 1998.

3
In the Abstract

• Directory architecture includes a person
  registry
• Person registry synchronizes records
• Input from administrative applications
• Supports LDAP, student email, WebCT, OneCard, Rec
  Center access, etc

4
Overview

• Introducing the real killer app
• Defining Enterprise Directory Architecture
• WebCT Provisioning Part one
• Student Email Provisioning
• Next! Student Rec Center
• WebCT Provisioning Part two
• Future Provisioning

5
Introducing Killer App

• Benefits of LDAP enterprise directory well
  articulated
• Looking for killer app?
• We often say that the overall integration and
  unification a general-purpose directory
  infrastructure enables is the real killer app
• The Burton Group, The Enterprise Directory Value
  Proposition

6
Defining the Architecture

• Directory name, title, dept, address, phone
• LDAP compliant interface
• Logical join HR, student, alumni, affiliate
• Person Registry is the join mechanism
• Core person attributes- data stewards help
• Incremental approach
• NB Enhance, dont replace, existing apps

7
Defining the ArchitectureResources

• www.internet2.edu/middleware
• Identifiers, Authentication, and Directories
  Best Practices for Higher Education
• The Burton Group
• Developing a Directory Architecture, 3 tier model
• Directory Project Cookbook, cross-functional
  management, high-level sponsor, iterative
  approach
• Bob Morgan
• Person Reg Phase I Tasks, checklist

8
Defining the ArchitectureResult

• GSU Person Registry
• Initial person registry design
• Entity relationship diagrams
• Overall architectural model
• Process flows from source systems
• Specific file record definitions for source data
• Starting point (But, more scenarios would be
  nice)

9
WebCT ProvisioningPart 1

• Faculty want automated WebCT accounts
• Sept 2000 Goal do so by January 2001
• Advantages of being first
• No existing object constraints
• One population selection students in courses
• Familiar extract, several existing code sections
• Oracle tables basic
• RIKEY unique ID for simple joins of tables

10
(No Transcript)
11
WebCT

• Core student info via nightly batch
• STUFILE table
• Represents nightly batch
• Reference for pre-transformation
• Audit? tie back to original
• STUFILE mapped to STUDENT and undergoes
  transformations

12
(No Transcript)
13
WebCT

• Transformations to STUDENT include
• RIKEY becomes key, SSN only attribute
• Name is SIS_Name
• Code lookups LAST_activity fields added
• Operational info (DATE_Created) added
• Some data in other tables
• ADDRESS, Courses, WebCT info
• STUFILE_CHANGES table holds change info
• STUDENT mapped to PERSON table

14
(No Transcript)
15
WebCT

• PERSON master table
• DISPLAY formats of data
• PRIMARY_AFFILIATION added (Student)
• Name components (first, middle, last)
• ISO and BARCODE?
• Identifiers still provisioned from OC_Tables
• Legacy issues oh yeah, the past
• Migration is stepwise

16
WebCT ProvisioningObservations

• Person Registry flexible, not constrained by
  complex design
• Student info kept redundantly (source, load file,
  transform table, Master Person)
• WebCT ids assigned in registry process, file
  output for WebCT
• Magically enrolled WebCT courses
• WebCT API bug oops, whats with that?

17
Student EmailStarting to Prioritize

• Steering Group sets overall priorities
• Person Registry Task List weekly status
• Incremental implementation methodology but
  awareness of longer term
• LDAP to replace CSO directory
• Authoritative repository on persons
• Applications dont forget previous queue

18
Student Email

• Dec 2000, Student Email Web Definition
  Committee recommends policy
• All students get email
• This system was made possible by the 2001
  Student Technology Fee, and is effective June 11,
  2001. (Whoa!)
• Email, Lab access, file space, web space

19
Student EmailRaising the Bar

• Single userid/pw for multiple services
• Holy grail for enterprise solutions
• Userid activation includes authentication
• Person registry sets userid, initial pw
• Student app provides authentication (legacy)
• So password resets can be self service
• (Future Questing Account Management)

20
Student EmailRaising the Bar

• Not just enrolled need more attributes
• Admitted, eligible to enroll, registered
• Monitor expiry of status
• Maintain active inactive flags
• Business rule Whats email policy intent?
• NB inactive remain in person registry
• Build privilege objects as needed

21
Student EmailRaising the Bar

• Ta Da! LDAP is part of the solution!
• Novell NIMS (Network Internet Messaging System)
  supports any IMAP, LDAP client
• Person registry provisions NIMS via LDIF
  transaction sets
• Person registry construct enables recovery of
  LDIF transactions

22
Next! Student Rec Center

• High profile, funded by student fees
• Opening August 2001 access needed
• New registry persons staff, alumni, affiliates
  matching required
• Data store requirements for elements not in any
  source system
• On time (and Goodbye to OC_Tables)

23
Student Rec Center

• Expanding registry population
• Matching (avoiding duplicates) needed
• Legacy HR app does check legacy student
• If matches SSN, prefills address, phone, gender,
  race, DOB (not name, its a format issue)
• What if SSN wrong or cant match to student
  Temp_SSN_Number?
• Maintain separate tables for student, staff
• Matching always with us Open Issue

24
Student Rec Center

• Data store requirements
• Affiliates records
• No surprise, expected
• Does require interface (avoid duplicates!)
• Must have sponsor record
• Multiple affiliations possible (how handle as
  moves beyond Rec Center?)

25
Student Rec Center

• Data store for liability waiver
• Unexpected
• Rec Center business liability requirement
• Special business rules internal to Rec Center
• Fees paid issue
• Not your registrars fees paid!
• What if affiliate, staff not using payroll
  deduction, Alumni?

26
Student Rec CenterOn Time Bonus Round

• OC_Tables are dead, long live registry!
• ISO, Barcode now assigned at registry
• PantherCard printing feeds from registry
• PeopleSoft financial interface to person registry
• Library feed part of person registry (not yet
  from person registry)
• Uhhh, did we mention Production?
• Did we mention security?

27
WebCT ProvisioningPart 2

• Recall WebCT API bug January 2001?
• Rebuilt WebCT provisioning for Fall 2001
• (Work around API remains open issue)
• NameSpace issues
• Student Flastname_at_student.gsu.edu
• Faculty/Staff Flastname_at_gsu.edu
• How distinguish better? Is it a Unique ID?
• Tough to resolve in production mode!!!

28
WebCT ProvisioningPart 2

• Students will have single userid/pw for
• Email, Lab access, file space, web space
• and WebCT

29
Future Provisioning

• Addressing NameSpace issues
• Immediate need for email and UID
• Email groups very hot
• Enhanced Library feed
• Non-trivial how many patron groups are there?
• LDAP White Pages CSO migration
• That means redoing sendmail
• Requires self-service for WP entries

30
Future Provisioning

• FERPA and access issues
• Prerequisite for LDAP White Pages
• Okay, so how provision if no attributes? OPEN
• Account management support
• Buying solution is expensive
• Building solution may be complex
• But customers want services
• And auditors want security

31
Future Provisioning

• PKI deployment
• Synchronization using Metamerge
• www.metamerge.com
• Move from batch file processing to transaction
  processing
• Provide immediate registry update for
  self-service request
• Auto update of source systems? LDAP WP?
• Annual phonebook printing

32
Future Provisioning

• SCT Banner Student integration
• PeopleSoft Human Resources integration
• Security, production, resources
• Your applications here
• Use additional lines as needed
• ____________________________
• ____________________________
• ____________________________

33
Conclusion almost

• The person registry is a core component of an
  enterprise directory architecture
• Remember slide 8s last bullet?
• Starting point (But, more scenarios would be
  nice)
• Weve been discussing the scenarios.

34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
(No Transcript)
39
Questions, Comments?