Middleware Services SUNY at Buffalo

1
Middleware Services SUNY at Buffalo

• Daniel Arrasjid
• http//www.tiad.buffalo.edu
• daniel_at_buffalo.edu

2
Overview

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

3
UBs 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
UBs 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 IDs 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
  
• IDs 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
• Users 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 persons 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 graduates
  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 Gradients 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 ProC/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 isnt 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/internet
  2middleware
  
• Decorum presentations
• http//www.tiad.buffalo.edu/presentations/decorum9
  8
  
• http//www.tiad.buffalo.edu/presentations/decorum9
  9
  
• UBs 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_at_buffalo.edu

42
Questions?

• ???