Middleware Services SUNY at Buffalo

1. Middleware Services SUNY at Buffalo Daniel Arrasjid http://www.tiad.buffalo.edu daniel@buffalo.edu

2. Overview • Environment and assumptions • Goals • Major components • Identify Management • Authentication Services • Directory Services • Costs / Challenges • References • Questions?

3. UB’s Environment • 26,000 enrolled students • 12,000 non-student affiliates • Central IT • Mainframe-based and UNIX-based administrative systems • Unix timeshare • 600+ Windows NT/Unix public computing lab workstations • IMAP mail • Web-based student services • 6000+ Student Dormitory Ports(ResNet) • Student Apartment Ports • 1000+ High Speed Dial-up lines • LDAP • Other services

4. UB’s Environment • Distributed IT • Departmental labs and support • Desktop support • Specialized services • Departments often rely on central IT services • Shared username and group namespaces • Shrinking IT budget • Access99 - Student Access Initiative • incoming freshman computer requirement, UB Wired • Internet2 member, OC3 connect to NYSERNET(OC12 vBNS and Abilene) • Gigabit backbone phase I completed, project completion by Fall 2000 • Consensus building, campus discussions take a long time • IT now considered Mission Critical to the University

5. Identity Management - Personal • UB IT name(DCE) is the primary campus-wide identifier • resolves to an opaque number that is the primary index for the physical entity • Other true personal campus-wide identifiers, all inter-linked: • UB Person ID(8 digit number assigned to all affiliates) • UB Multi-function Identification Card(ISO number) • Library Patron Number(barcode) • Social Security Number • e-mail addresses • Meta-directory stored in Oracle database • Provides mappings between all the identifiers • Contains institutional organization model data

6. Identity Management - Personal • Populations Eligible to get ID: • All Students • Faculty • Staff • Visitors • Volunteers • Contractors • Special procedures for handling extended populations • Sponsored, departmental ID’s with limited privileges

7. Identity Management - Personal • Identifiers are used for: • Administrative applications • Web-based student registration, unofficial, transcripts, others • MyUB - custom content web portal • Web-based library resources • E-mail(IMAP/POP) • ldap.buffalo.edu modifications • Resnet(Student Dorms) • Open Ports • Dial-up PPP • UBFS - Institutional Distributed File System • Public NT/UNIX lab workstations • UNIX timeshare/batch services • Mainframe Connectivity • Campus web service

8. Identity Management - Personal • Automated procedures when an ID is assigned: • Creation of campus-wide authentication entry • Creation of e-mail accounts • Creation of timeshare accounts • Creation of UBFS space(DFS) • Creation of LDAP entries • Authorization attributes assigned to ID • Automated procedures when object affiliation expires: • Latencies built into system to accommodate upstream issues • Students have 6 month grace period after graduation • Timeshare accounts/UBFS space archived • LDAP entries removed • Authorization attributes removed from ID

9. Identity Management - Personal • One Person - One ID Policy • Person registry(data warehouse) of all University people • Automated management system performs datapoint checks • ID’s are mapped for life, no re-assignment of identifiers • Account names auto-generated • Algorithm attempts to find “good” identifiers • Most “good” identifiers are already consumed • User’s may change their identifier, when: • Legal name change • Undesirable auto-generated identifier not caught by stop list check

10. Identity Management - Objects/Groups • Organizations, projects, and groups may be assigned identifiers • Ownership tracked: • Back to institutional data • Sponsorship data • Certain object/group identifiers are subject to renewel

11. Authentication Services • Primary campus authentication system is DCE • Most central systems and services use DCE authentication, including: • Web-based student registration, unofficial, transcripts, others • MyUB - custom content web portal • Web-based library resources • E-mail(IMAP/POP) • ldap.buffalo.edu modifications • Resnet(Student Dorms) • Open Ports • Dial-up PPP • UBFS - Institutional Distributed File System • Public NT/UNIX lab workstations • UNIX timeshare/batch services • Mainframe Connectivity • Campus web service

12. Authentication Services • Initial passwords set algorithmically • Based on public and private data known only to the customer • Initial passwords provided to all customers via: • public lab swipe card stations • Custom freshman orientation materials • In-person with positive ID • Authentication system enforces strong passwords via customizable password strength library • No mandatory password change frequency • Compromised passwords are invalidated, customer must visit the security officer for account reinstantiation • When a person’s status changes • Authentication entry is never removed • Authorization attributes are updated

13. Authentication Services • Passwords are not synchronized across multiple campus-wide systems • UNIX-style password files are distributed to non-DCE UNIX systems • Departmental systems are not synchronized with the campus-wide authentication system • No special policies for users using secure passwords in non-secure environments(telnet, etc) • Encourage customers to use secure methods(SSH, etc) • Passwords are never kept in clear text on systems • Shared passwords are not allowed • Services authenticate via keytab files

14. Directory Services- White Pages • Netscape Directory Servers(LDAP) • Replicated service • Entries are updated daily • ldap.buffalo.edu • DNS name publicized in various places(web pages, campus publications, user handouts/documentation) • Internet access via Web interface only • Campus network access via Web and native LDAP tools • Directory entries user-updateable via web interface • Directory entries have two components: • Institutional data • User supplied data

15. Directory Services- White Pages • Student, Faculty/Staff, and hospitals’ staff are combined in one DS • Students may suppress all data except: • e-mail address • campus-wide authentication identifier • Faculty/Staff • may not suppress any data • no personal/residential data • DS policies somewhat mirrors paper phone book policies • People may not use multiple name forms, nor nicknames • Other entries to be added by Spring, 2000 • “Blue Pages” data • Service e-mail aliases data • Data policies are not published, but provided to bulk consumers

16. Directory Services- White Pages • DS is designed to not be easily trolled: • Restrictions on number of entries returned • Native LDAP queries restricted to on-campus network • Off-campus queries are restricted to web interface(not designed for bulk queries) • White pages DS is integrated with system management DS, both indexed by person number • Supports end-user DS clients: Netscape, Mulberry, Simeon, MS, others

17. Directory Services- System Management • System Management Directory Service is based on DCE • Most centralized services make use of this directory data(see previous slides) • Application Servers and File Services are in this DS • The service is replicated

18. Challenges / Costs • Challenges • Buy-in / Marketing • Account Management • Integration • Costs • Training • Hardware • Software • Development / Integration • Salaries

19. Some Details - slides under construction • What is within and outside the DCE world on campus? • Most centrally supported services use DCE • DCE-based authn requirement for all new services • Old services being retrofitted where possible • Providing libraries with abstract DCE details to departments that want to leverage DCE-based authentication/authorization

20. The Old Way • Clerical staff obtains list of new students at start of semester • Hand-run scripts generate form letter for each student documenting their username and password • Staff and faculty added manually as needed • Clerical staff obtains list of graduating students at end of semester • Hand-run scripts deactivate each graduate’s account

21. Problems With the Old Way • Too much manual intervention • Inaccurate data • Keyboarding errors • Incomplete information • Deactivation difficult • Infrequently done • Scripts tied to specific platforms and locations • Very centralized • No auditing • Inflexible

22. Replacement System Goals • Most account manipulation should be done automatically based on institutional data • Account creation • Account deactivation • Automated management of account-related services • Platform independent client tools • Auditing • Account name and password available without staff intervention • Relationship between account name and institutional ID lives forever • Secure and authenticated admin access

23. Components • Account Management Scripts • Account Management Database (AMD) • Distributed Management Server (DMS) • Supplemental Servers • Filesystem manipulation (NFS/DFS) • Mailbox manipulation (Cyrus IMAP) • Client Tools • Graphical user interface (GUI) • Command-line interface (CLI)

24. Database Relationships IMAP HR Systems Infosource Account Management Database UB Card System LDAP DS Libraries DCE DFS & NFS Building Access

25. Component Relationships Account Management Scripts Web Client CLI Client Gradient Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

26. Client Software Account Management Scripts Web Client CLI Client Gradient Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

27. Client Software • DCE RPC allows for multiple clients to suit different needs • Command-line client • Used by automated account management scripts • Simple due to limited needs • Input provided by trusted applications (not humans) • GUI client is used for manual management of data • Can only modify certain kinds of data • Good for exceptions

28. GUI Client • Uses Gradient’s Net Crusader • Reasonably Secure • SSL from client desktop to Gradient SA • DCE RPC from SA to RPC server • Displays only actions user has privileges for • Web interface allows for location independence

29. Distributed Management System Account Management Scripts CLI Web Client Gradient Client Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

30. Distributed Management System • High-level account manipulation facility • Some enforcement of University policy • Provides delegated management of shared namespaces • ACL manager based control • Full auditing of all account and group transactions

31. Why Add Indirection? • DCE is well suited for distributed computing • DCE is not designed for distributed account management • Registry ACLs not fine-grained • Built in auditing is limited • An account is more than just an entry in the DCE registry • DFS • NFS • Mail system • Others

32. Account Management Scripts Account Management Scripts CLI Web Client Gradient Client Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

33. Account Management Scripts • Glue between institutional databases (payroll, registrar, etc) and DCE principal • Small collection of OraPerl and Pro*C/DCE programs • Daily data comparison determines what changes are needed • Automated actions • Account creation (new institutional identity) • Deactivation of accounts • Reactivation of deactivated accounts • Group membership

34. Account Management Database Account Management Scripts CLI Web Client Gradient Client Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

35. Account Management Database • Oracle database • DMS interface manipulates tables • mapping between institutional IDs and DCE principal • Account status, timers, etc. • Some tools access database directly • Kiosks equipped with University ID card swipe readers obtain username and password algorithm • Exports to campus LDAP directory • Exports of ID-to-principal mapping to campus datawarehouse

36. Service Management Account Management Scripts CLI Web Client Gradient Client Client Filesystem RPC Server IMAP RPC Server DMS Account Management Database DCE DFS NFS IMAP

37. Service Management • Small DCE RPC servers • Abstraction similar to DMS • Currently used for NFS, DFS, and IMAP • Houses some local policy information • Filesystem structure for homedirs • Quota allocations

38. Some Problems • Institutional data feed isn’t always reliable • Buffering mechanism was needed • Defining “affiliation” at a public university can be hard • Many odd situations, unwritten rules, etc • Much of the work was spent adding exception capabilities to the client tools without introducing loopholes • Authorization “Privacy” issues • Class registration-based authorization attributes can be used to determine where a student is at a specific time • Number of accounts bogging down some services • Bugs in development tools • Taking much longer than expected

39. Future Development • Providing admin tools to departments • Currently piloting • Provide some database queries via GUI tool • Account history • Diagnostic information • Finish the documentation!

40. References • This presentation: • http://www.tiad.buffalo.edu/presentations/internet2middleware • Decorum presentations: • http://www.tiad.buffalo.edu/presentations/decorum98 • http://www.tiad.buffalo.edu/presentations/decorum99 • UB’s DCE web site • http://www.tks.buffalo.edu/dce • SUNY at Buffalo Web Sites • http://www.buffalo.edu - external • http://wings.buffalo.edu - external/internal

41. TIAD Group at SUNY at Buffalo • TIAD - Technology Integration & Architecture Development • New(10 months) Internal Consulting Group: • IT Project Management • Systems Integration • Research and Development • Consulting • Proof of Vision / Proof of Concept • Standards/Interoperability Championship • http://www.tiad.buffalo.edu • daniel@buffalo.edu

42. Questions? ???