1 / 81

Middleware Implementation Case Studies

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. Middleware Case Studies.

otto
Download Presentation

Middleware Implementation Case Studies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

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

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

  32. Mini Case I Synchronizing iPlanet and ADRob Banz

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

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

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

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

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

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

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

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

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

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

More Related