1 / 42

Middleware Early Adopters Report: Technical Implementations

Middleware Early Adopters Report: Technical Implementations. 31 October 2000. Panelists. Tom Barton, University of Memphis Louise Miller-Finn, Johns Hopkins University Jack Suess and Rob Banz, University of Maryland, Baltimore County

lance
Download Presentation

Middleware Early Adopters Report: Technical Implementations

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 Early Adopters Report:Technical Implementations 31 October 2000

  2. Panelists • Tom Barton, University of Memphis • Louise Miller-Finn, Johns Hopkins University • Jack Suess and Rob Banz, University of Maryland, Baltimore County • Moderator: Ken Klingenstein, Internet2 /University of Colorado Internet2 Fall 2000 Meeting: Early Adopters Report

  3. Early Adopters Middleware Reports Technical Implementation The University of Memphis Dr. Tom Barton

  4. Initial Middleware Architecture Internet2 Fall 2000 Meeting: Early Adopters Report

  5. Project Scope • Replace or reengineer Ph applications • Enhance existing data feeds from administrative systems • New metadirectory solution andregistry process • Group messaging & group authorization facilities • New account maintenance facilities & practices • Prepare for next stage: PKI and Roles Internet2 Fall 2000 Meeting: Early Adopters Report

  6. Final Middleware Architecture Internet2 Fall 2000 Meeting: Early Adopters Report

  7. LDAP SMTP Routing • Two phases: Identification & Routing • Routing issue: when to rewrite envelope recipient • One solution: “LDAP routing domain” concept Definition: all MTAs that use the same set of LDAP searches against the same directory for the same set of SMTP domains to make email handling decisions. Guideline: Entries whose mailbox resides on a mailbox host inside the LDAP email routing domain should only have mailHost populated. Other entries should only have mailRoutingAddress populated. With this guideline, it is unnecessary to ever have both attributes populated. Internet2 Fall 2000 Meeting: Early Adopters Report

  8. LDAP SMTP Routing (cont’d) Internet2 Fall 2000 Meeting: Early Adopters Report

  9. LDAP SMTP Routing (cont’d) • That complicated real world legacy: • Old “Ph aliases” still had to be deliverable. • Fallback routing methods embodied in custom extensions to phquery • Aliases files on mailbox hosts being retired • “Vanity” email domain addressing • Put legacy addresses in mailAlternateAddress • Analyze mail logs proactively to catch legacies • Leave “passthru mode” enabled for a good while Internet2 Fall 2000 Meeting: Early Adopters Report

  10. Group Messaging & Authorization • Populate LDAP group objects to support authorized access to email distribution lists & web resources. • Top-down; majors; class; section; org related • LDAP backed SMTP AUTH over TLS used to identify poster’s uid. LDAP (uid=) search to find poster’s DN, which is compared to a list of permitted DNs for each mail group. • Uses Netscape Messaging Server’s mailGroup objectclass for its “allowedBroadcaster” attribute. Internet2 Fall 2000 Meeting: Early Adopters Report

  11. Representing Organizational Structure • Labelled organizational hierarchy tree structure from: • FRS responsibility rollup • FRS DBD • Ad hoc rules to prune or identify certain nodes and to create realistic labels (the hardest part) • Payroll data is then used to assign each employee to one or more nodes in the tree. • FRS security file indirectly identifies dept heads at each node. • Tree is mapped to ou=orgUM branch of DIT and org-related attributes of people objects. Internet2 Fall 2000 Meeting: Early Adopters Report

  12. Representing Organizational Structure (cont’d) • ou=Anthropology, ou=College of Arts & Sciences, ou=Provost, … • umOrgDeptHead: <DN> single-valued • umOrgBudgetHead: <DN> multi-valued • umOrgMemberGroupDN: <DN of groupOfUniqueNames> • umOrgRollupMemberGroupDN: ditto • umOrgRollupDeptHeadsGroupDN: ditto • umOrgRollupBudgetHeadsGroupDN: ditto • People attributes: • ou: <list of ouRDNs> • umRollupID, umSuperiorRollupID: <FRS rollup IDs> single-valued Or labeledURI in searchGuide? Internet2 Fall 2000 Meeting: Early Adopters Report

  13. Representing Roles & Sets of Correlated Information • Example: jdoe is faculty in Law & staff in Econ. Don’t want jdoe when searching for faculty in Econ. • role: {-affiliation:faculty-dept:law, -affiliation:staff-dept:Econ} • roleDN: {DN of role1, DN of role2} • cn=role1, ou=Roles, … • roleDept: Law • roleAffiliation: Faculty • … • cn=role2, ou=umRoles, … • roleDept: Econ • roleAffiliation: Staff Internet2 Fall 2000 Meeting: Early Adopters Report

  14. Early Adopters Middleware Reports Technical Implementation Johns Hopkins University Louise Miller-Finn

  15. Johns HopkinsDirectory Data Flows • Establish methodology for populating the directory • Select vendor products and tools • Establish standards • Staff the team • Use iterative development cycle Internet2 Fall 2000 Meeting: Early Adopters Report

  16. Johns HopkinsStage 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 • Produce audit log Internet2 Fall 2000 Meeting: Early Adopters Report

  17. Johns HopkinsStage 2 – Database Requirements • Define the input tables to represent the clients’ data; define key fields to tie tables together; • Provide data model using an Entity Relationship tool (e.g. ERWin); • Document and store common database procedures; • Provide standard database templates for reuse; • Provide audit log Internet2 Fall 2000 Meeting: Early Adopters Report

  18. Johns HopkinsStage 3 – Back End Processing • Develop procedures (PLSQL) to process high level business rules; • Implement ER diagrams that define table fields; • Create intermediate tables with directory records; • Store common procedure templates for reuse; • Provide audit log Internet2 Fall 2000 Meeting: Early Adopters Report

  19. Johns HopkinsStage 4 – Database Export • Create 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 Internet2 Fall 2000 Meeting: Early Adopters Report

  20. Johns HopkinsStage 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 based report interface to track activity and status; • Provide audit log Internet2 Fall 2000 Meeting: Early Adopters Report

  21. Directory Structure

  22. Johns HopkinsStage 6 – Directory Status • Provide complete audit log of directory activity; • Create and store common report template; • Generate standard web based activity report; • Provide backup/recovery procedure; • Provide replication service Internet2 Fall 2000 Meeting: Early Adopters Report

  23. Johns HopkinsStage 7 – Front End Processing • 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); Internet2 Fall 2000 Meeting: Early Adopters Report

  24. Johns HopkinsStage 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 an audit trailer record; Internet2 Fall 2000 Meeting: Early Adopters Report

  25. Johns HopkinsIterative Development Cycle • Provide complete data-to-directory path; • Push the data through one cycle to kickoff development process; • Each iteration flushes more detail to the requirements in a rapid application development process adding data, business rules and/or policy changes; • Each iteration provides intense unit testing followed by QC test cycle; Internet2 Fall 2000 Meeting: Early Adopters Report

  26. Early Adopters Middleware Reports Technical Implementation University of Maryland Baltimore County Robert Banz

  27. UMBC – Present Architecture Internet2 Fall 2000 Meeting: Early Adopters Report

  28. UMBC – Hardware & Software • Hardware • 1 Sun Enterprise 220 (2x CPU, 2G RAM) – Primary Directory Server • 2 Sun NetraT1 – Slave Directory Servers • Software • iPlanet (Netscape) Directory Server • Loads and loads of Perl Internet2 Fall 2000 Meeting: Early Adopters Report

  29. UMBC – Person Directory • Contains over 275,000 Entries from: • Human Resources -- in Oracle • SIS – Resides on an HP MPE machine, data is mirrored “almost real time” into Oracle • PH/CSO Database Contents (retired) • “Other” entities not contained in either of these data sources • Not (yet) the System of Record Internet2 Fall 2000 Meeting: Early Adopters Report

  30. UMBC – Directory Schema • “Flat” person directory • Uses “umbcPerson” objectclass • Derived from InetOrgPerson • Proposed “eduPerson” attribute names & definitions used when possible. • Account management data stored in RFC2307 (NIS Objects in LDAP) compliant schema. Internet2 Fall 2000 Meeting: Early Adopters Report

  31. UMBC – Data Synchronization • Currently “One-Way” • (changes must still be made through legacy applications and myUMBC web portal) • Changes to HR & SIS data are written to a log table via PL/SQL triggers • Perl daemon constantly checks the log table and takes appropriate action Internet2 Fall 2000 Meeting: Early Adopters Report

  32. UMBC – Directory Enabled Applications • WebAdmin • UNIX Account Management (self service and administrative access) • Person Directory Management • Email Namespace Management • MyUMBC • Uses directory to resolve “people” from “usernames” • @umbc.edu EMail Addresses • Destination addresses of all @umbc.edu are resolved via a LDAP map in Sendmail. • Replaced PH/CSO “phquery” Internet2 Fall 2000 Meeting: Early Adopters Report

  33. UMBC – Future Applications • @umbc.edu Email Addresses for Alumni • Tighter integration of On-Line course tools (WebCT, Blackboard), including: • Automagic enrollment of students in registered courses • “Single Sign On” to campus Web services • Integration with PeopleSoft • Most likely will become the “Registry of Record” Internet2 Fall 2000 Meeting: Early Adopters Report

  34. For More Information • www.internet2.edu/middleware/earlyadopters/ • University of Memphis • Tom Barton tbarton@memphis.edu • Johns Hopkins University • Louise Miller-Finn lmiller@jhmi.edu • University of Maryland, Baltimore County • Jack Suess jack@umbc.edu Internet2 Fall 2000 Meeting: Early Adopters Report

More Related