Middleware Implementation Case Studies

1. Middleware Implementation Case Studies Tom Barton, The University of Memphis Renee Woodten Frost, Internet2 & UMich Louise Miller-Finn, Johns Hopkins University Dewitt Latimer, University of Tennessee Todd Piket, Michigan Tech University Robert Banz, UMBC

2. Middleware Case Studies Agenda • Introductions - Tom • Setting the Middleware Stage - Renee • Case Studies: U of Memphis – Tom Johns Hopkins – Louise BREAK 2:30pm • Mini Cases iPlanet to AD – Rob, UMBC eduPerson – Todd, MTU Multi-campus Directory – Dewitt, Tennessee Network Access Services – Tom, Memphis E-Provisioning – Louise, Hopkins BREAK 3:30pm Round Table Discussions • Wrap up - Tom • Ongoing Middleware Initiatives – Renee

3. Middleware Case Studies Introductions …. and tell us about your middleware “burning issue”

4. Core Middleware Identity - unique markers of who you (person, machine, service, group) are Authentication - how you prove or establish that you are that identity Directories - where an identity’s basic characteristics are kept Authorization - what an identity is permitted to do PKI - emerging tools for security services

5. Mapof Middleware

6. Organizational Drivers • Federal government • E-enterprise functions • Service expectations • Resource allocation pressures • Collaboration

7. Benefits to the Institution • Economies for central IT - reduced account management, better web site access controls, tighter network security... • Economies for distributed IT - reduced administration, access to better information feeds, easier integration of departmental applications into campus-wide use... • Improved services for students and faculty - access to scholarly information, control of personal data, reduced legal exposures... • Participation in future research environments - Grids, videoconferencing, etc. • Participation in new collaborative initiatives - DoD, Shibboleth, etc.

8. Costs to the Institution • Modest increases in capital equipment and staffing requirements for central IT • Considerable time and effort to conduct campus wide planning and vetting processes • One-time costs to retrofit some applications to new central infrastructure • One-time costs to build feeds from legacy source systems to central directory services • The political wounds from the reduction of duchies in data and policies

9. Nature of the Work • Technology • Establish campus-wide services: name space, authentication • Build an enterprise directory service • Populate the directory from source systems • Enable applications to use the directory

10. Nature of the Work • Policies and Politics • Clarify relationships between individuals and institution • Determine who manages, who can update and who can see common data • Structure information access and use rules between departments and central administrative units • Reconcile business rules and practices

11. Enterprise Directory Service: What Is It? • Anti-stovepipe architecture that can provide authentication, attribute, & group services to applications. • Adds value by improving cost/benefit of online services and by improving security. • A new & visible flow of administrative data. When someone finally begins to understand what you’re talking about, they react to the prospect of change.

12. Managed Objects • Objects that describe: • People • Groups • Aliases, Roles, Affiliations • Network devices • Security policies • Network services • Org structure • The object classes and source data to populate them are determined by the applications to be directory enabled.

13. Enterprise Directory Service:How To Build One • Determine application-driven requirements for authentication, attribute, and group services and then design these four stages to meet the requirements: • Data Sources • Metadirectory Processes • Directory Services • Applications

14. UoM Core Middleware Stages Data sources Metadirectory processes Directories Applications

15. Notes re: UoM Core Middleware Stages • Data Sources: Attribute selection; negotiation for access; determination of data access policy; familiarity with semantics of desired data elements & business processes that maintain them. • Metadirectory Processes: Management of identity; transformational & business logic (resource provisioning); derived attributes & structures (eg, uid’s, email attributes, state variables, org structure groups & attributes, …). • Directory Services: Loading & replicating; access controls for directory information; schema extensions to support applications; indexing & performance management; synchronizing other consumers of directory info.

16. Notes re: UoM Core Middleware Stages Applications. Some boxes represent classes of apps. Tigerlan (800 seats of computer labs); white pages (people search); Library proxy access; postoffice & calendar account building; manage mail account (vacation, quota, …); various web-based utilities for LSPs; ResNet autoregistration; secure discussion groups; campus pipeline; UoM “address book” integrated into email clients; IMAP/POP/web accessible emailboxes; calendar; email routing; off-campus email relay provided only to authenticated users; mass email; dialup & wireless authentication & authorization; card swipe facilitated account self-maintenance; automated account & resource management (“misc actions” in the slide).

17. Notes re: UoM Core Middleware Stages Applications - upcoming: WebCT; data warehouse; suite of applications directly managed by AD; shell account, home directory & personal web page access; FASTLane (Faculty & Staff LAN); storage & distribution of digital certificates, a key element of PKI; PIN synchronization??; new UoM ID card based applications??; authentication of Library patrons??

18. HRS: All accounts paid from, not just primary department. SIS: Select students from current, future, and previous term and add’l data elements to support 2nd generation group messaging. Pull instructor data too. ADS (Alumni): initiate DRA (Library): initiate Async (Clientele): New web based account self-maintenance to replace card swipes. “Challenge” Qs & As for identification in non face-to-face circumstances. Issues With Current Data Sources

19. Issues With the Current Metadirectory • NDS update channel is too slow • Ancient, frozen technology (especially Ph) • Anticipate new policy regarding account & resource management, especially to handle off-campus students & alumni. • 9 years of spaghetti • Tightly bound to particular source and directory technologies.

20. Issues With Current Directories • Must bring Active Directory into this infrastructure. • Need better representations & procedures for non-people objects: static groups; dynamic groups; org structure related groups, roles, and people attributes; affiliations & other “correlated” info. • Need to include new types of metadirectory consumers such as list processors

21. MetaDirectory Data Pump Overview • Provide complete SOR data-to-directory path; • Push the data through first cycle to kickoff development process; (prime the pump) • Review first iteration, and prepare next iteration with updates; • Each iteration flushes more detail to the requirements in a rapid application development process adding data, business rules and/or policy changes; • Document and store standard deployment procedures; • Each iteration provides intense unit testing followed by QC test cycle, then move to production

23. Stage 1 – Analyze Data Sources • Common Identifiers on campus • Identify systems of record and data owners • What data do we need? • Frequency of the feed • Provide Standard Data Collection Model • Define database load procedure and produce audit log

25. Stage 2 – Database Requirements • Create tables to mirror the feeder files • Establish key using most common identifier • Create and use loader scripts that can be re-used • Track nightly loads to log, reporting exceptional situations using thresholds

27. Stage 3 – Back End Processing (BEP) • Load data using weighted priority • Full time affiliation creates the record • Secondary systems add value to a person’s data • Eligibility for services determined and flagged • Unique friendly login id assigned • Unique opaque id assigned and stored • Result: one record per person

29. Stage 4 – Database Table Export • Compare today’s data with yesterday (t vs t-1) • Insert operation into record • Add, Update, Delete, No Change • Write the export file if status = active in any primary system of record

31. Stage 5 – Directory Import • Process export files using generic (PERL) script to import/update enterprise directory; • Keep code free of business rules; • Provide web base report interface to track activity and status; • Provide audit log • Found that mass deletes would crash the system

33. Stage 6 – Directory Status • Web interface into the operational integrity of the data pump • Monitor thresholds of activity • Monitor backups • Monitor replication services • Monitor application proxy server load/failovers

35. Stage 7 – Front End Processing (FEP) • Define and deploy access control (ACL); • Define JHI policy for the global user, the person, and the administrator; • Develop and document scope and visibility to the directory attributes; • Develop and deploy common web enabled directory access (a common ‘look and feel’ to the front end); • Use a common set of development tools (e.g. ColdFusion); • Apply front end application level business rules (more specific rules than the back end process);

36. Stage 7 – Front End Processing (FEP) • Developer Tool Kit • Registration application – EDIR • Example code snip-its for authN and authZ • Cold Fusion, JAVA, ASP, VB • Directory-enabling an application ‘process’ • 10-12 applications in the queue • Demanding of our time • May outsource

38. Stage 8 – Directory Updates • Our Holy Grail…..we receive the updates and feed them back to the systems of record. • We are no longer held accountable for their “bad data” and the institution has a central site for all updates, no matter who they are.

39. Summary • Don’t underestimate the need to keep repeating the message • Support from the top is critical • Continual auditing: data feeds will disappear or show up corrupted • Hire the best, otherwise you will waste much time and $$$ • Maintain KISS principle

40. Mini Case I Synchronizing iPlanet and ADRob Banz

41. Background • UMBC’s Stats: • Enrollment of approx. 11,200 • 750 full & part-time faculty, 1500 staff

42. Existing Infrastructure • iPlanet-based LDAP directory • Kerberos 5 used for authentication • Campus-wide AFS-based file-store • For instructional, research, and other use • LAN file & print services provided by Novell 4 • Used by administrative & academic departments

43. Why Not AD Everywhere? • Pros: • Reasonably well performing LDAP server • Already part of Win2k Server • Powerful schema managment • Cons: • Objectclass/Attribute definitions not 100% standard • ex: cn (Common Name) not Multi-Valued • New, “unproven” technology

44. The Problem • Integrate: • Existing campus directory and account management system, based on the iPlanet directory server • Existing campus-wide authentication, based on MIT Kerberos 5

45. Kerberos 5 Integration • Already “supported” by Microsoft! • http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerbstep.asp • Solves “most” of the authentication problem … more on this later.

46. Resources • Directory Team • Experienced with LDAP • Existing directory tools & connectors written in Perl • Group generally takes on software development projects • Windows/LAN Team • Little LDAP experience • Little Active Directory experience … does anyone have a lot ? • Not a software development oriented group

47. Choices… • Updates: • Batch, or • “real time” ? • Development platform • Windows w/ADSI, or • UNIX w/Perl ?

48. Our Choice • Develop on Unix with Perl – our platform of choice • Aim for near “real time” updates

49. Components Needed • Interface to the iPlanet Directory Server’s “changelog” (already have) • Logic to create Active Directory account “objects” from a “umbcAccount” object • Interface to the Active Directory

50. Translation Logic • Perl module • Given a “umbcAccount” LDAP entry, generate an appropriate Active Directory entry • Includes a “standard” API used by the changelog interface