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

2. Outline of Presentation • Renee will introduce the concept of Core Middleware and the reasons for implementation • Tom will give an overview of the structure of an Enterprise Directory Service and identify some issues currently facing the U of Memphis. • Louise will detail the Johns Hopkins model for an Enterprise Directory Service. • Renee will summarize some additional related Internet2 Middleware Initiative activities.

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

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

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

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

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

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

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

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

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

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

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

14. 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).

15. 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??

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

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

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

19. MetaDirectory Data Flow Overview • Provide complete SOR data-to-directory path; • Push the data through one 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 procedure; • Each iteration provides intense unit testing followed by QC test cycle, then move to production

21. Stage 1 – Analyze Data Sources • Identify Data Sources • Where do the data feeds originate; what data fields are required; Provide Standard Data Collection Model • What is the frequency of the data feed; require fixed length fields and records; • Define database load procedure and produce audit log

23. Stage 2 – Database Requirements • Define the input tables to represent the clients’ data; define key fields to tie tables together; • Document and store common database procedures; • Provide data model using Entity Relationship tool (e.g. ERWin); • Provide standard database templates for reuse; • Provide audit log

25. Stage 3 – Back End Processing (BEP) • Develop procedures (PLSQL) to process high level business rules; • Create intermediate tables with directory records; • Implement ER diagrams that define table fields; • Store common procedure templates for reuse; • Provide audit log;

27. Stage 4 – Database Table Export • Provide export file in fixed field, fixed record format; • Develop status field processing using eye catcher (e.g. ‘ADD’, ‘DELETE’, ‘UPDATE’, ‘NOCHANGE’) • Document export procedure and standard field values; • Create and store common export procedure template; • Produce activity log

29. Stage 5 – Directory Import • Process export files using generic (PERL) script to import/update enterprise directory; • Keep code free of business rules; • Create and store common script template for reuse; • Provide web base report interface to track activity and status; • Provide audit log

31. Stage 6 – Directory Status • Provide audit log of directory activity; • Create and store common report template; • Generate standard web based activity report; • Provide backup/recovery procedure; • Provide replication service;

33. 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);

35. Stage 8 – Directory Updates • Provide a log dataset of directory activity (updates, deletes, etc.); • Provide standard procedure for data owners to pull the activity log; • Design and implement a standard record layout using a status field and a audit trailer record;

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

37. Questions and Answers

38. Related I2 Directory Activities • Early Harvest / Early Adopters - http://middleware.internet2.edu/earlyharvest/ http://middleware.internet2.edu/earlyadopters/ • LDAP Recipe - http://www.georgetown.edu/giia/internet2/ldap-recipe/ • eduPerson – http://www.educause.edu/eduperson • Directory of Directories – http://middleware.internet2.edu/dodhe

39. Related I2 Middleware Activities • Shibboleth – http://middleware.internet2.edu/shibboleth/ • PKI – HEPKI-PAG, HEPKI-TAG http://www.educause.edu/hepki/ • PKI Labs http://middleware.internet2.edu/pkilabs/ • Vidmid – http://middleware.internet2.edu/video/

40. For More Information • Tom Barton tbarton@memphis.edu • Renee Woodten Frost rwfrost@internet2.edu • Louise Miller-Finn lmiller@jhmi.edu