Middleware Services SUNY at Buffalo

Presentation Transcript

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

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

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

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

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

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

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

Organizations, projects, and groups may be assigned identifiers
Ownership tracked:

Back to institutional data
Sponsorship data

Certain object/group identifiers are subject to renewel

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

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

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

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

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

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

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

Buy-in / Marketing
Account Management
Integration

Costs

Training
Hardware
Software
Development / Integration
Salaries

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

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

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

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

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

IMAP

HR Systems

Infosource

Account

Management

Database

UB Card System

LDAP DS

Libraries

DCE

DFS & NFS

Building Access

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

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

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

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

Account

Management

Scripts

CLI

Web

Client

Gradient

Client

Filesystem

RPC Server

IMAP

RPC Server

DMS

Account

Management

Database

DCE

DFS

NFS

IMAP

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?

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

CLI

Web

Client

Gradient

Client

Filesystem

RPC Server

IMAP

RPC Server

DMS

Account

Management

Database

DCE

DFS

NFS

IMAP

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

Scripts

CLI

Web

Client

Gradient

Client

Filesystem

RPC Server

IMAP

RPC Server

DMS

Account

Management

Database

DCE

DFS

NFS

IMAP

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