middleware services suny at buffalo l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Middleware Services SUNY at Buffalo PowerPoint Presentation
Download Presentation
Middleware Services SUNY at Buffalo

Loading in 2 Seconds...

play fullscreen
1 / 42

Middleware Services SUNY at Buffalo - PowerPoint PPT Presentation


  • 160 Views
  • Uploaded on

Middleware Services SUNY at Buffalo. Daniel Arrasjid http://www.tiad.buffalo.edu daniel@buffalo.edu. Overview. Environment and assumptions Goals Major components Identify Management Authentication Services Directory Services Costs / Challenges References Questions?. UB’s Environment.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Middleware Services SUNY at Buffalo


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
middleware services suny at buffalo

Middleware Services SUNY at Buffalo

Daniel Arrasjid

http://www.tiad.buffalo.edu

daniel@buffalo.edu

overview
Overview
  • Environment and assumptions
  • Goals
  • Major components
    • Identify Management
    • Authentication Services
    • Directory Services
  • Costs / Challenges
  • References
  • Questions?
ub s environment
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
ub s environment4
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
identity management personal
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
identity management personal6
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
identity management personal7
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
identity management personal8
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
identity management personal9
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
identity management objects groups
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
authentication services
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
authentication services12
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
authentication services13
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
directory services white pages
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
directory services white pages15
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
directory services white pages16
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
directory services system management
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
challenges costs
Challenges / Costs
  • Challenges
    • Buy-in / Marketing
    • Account Management
    • Integration
  • Costs
    • Training
    • Hardware
    • Software
    • Development / Integration
    • Salaries
some details slides under construction
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
the old way
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
problems with the old way
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
replacement system goals
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
components
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)
database relationships
Database Relationships

IMAP

HR Systems

Infosource

Account

Management

Database

UB Card System

LDAP DS

Libraries

DCE

DFS & NFS

Building Access

component relationships
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

client software
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

client software27
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
gui client
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
distributed management system
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

distributed management system30
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
why add indirection
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
account management scripts
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

account management scripts33
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
account management database
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

account management database35
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
service management
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

service management37
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
some problems
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
future development
Future Development
  • Providing admin tools to departments
    • Currently piloting
  • Provide some database queries via GUI tool
    • Account history
    • Diagnostic information
  • Finish the documentation!
references
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
tiad group at suny at buffalo
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