tapir user manager paul houle, library systems, cu library ph18@cornell.edu

Tapir User Manager

Paul Houle, Library Systems, CU Library

http://www.honeylocust.com/x/products/tum/

Ph18@cornell.edu

TUM Features• Cookie-based authentication

• Optional self-registration

• w/ e-mail address verification

• Automatic password resets

• Simple to integrate into existing applications

• Supports PHP and Perl applications

• Advanced Administrative Interface

• Add or Update User Records

• Real-time graphing

• E-mail sending to users

Why not Apache auth?Apache’s authentication is integrated with the web server, BUT:

•Users can’t log out

• No support for permanent login

• No automatic password reset

• Password file must be edited by hand

Web PortalsA web portal is a collection of web applications that share:

• Common visual appearance

• A single user database

User management is necessary for administrative screens, community, e-commerce, content management, etc.

The web software crisisTwo kinds of open-source and commercial web software:

• Frameworks

• Provide user management, templating, and other services, BUT

• Have a high-learning curve and almost always do something seriously wrong.

• Applications

• Many excellent apps exist, but since there’s no standard, they don’t share a user database.

So we re-invent the wheel for every site…

Performance GoalsAppropriate for small to large sites:

• PHP/MySQL combination is easy to install and maintain

• Supports > 1 M hits/day

• Doesn’t need to hit database to authenticate

• Supports > 1 M users

• Supports horizontal scaling

Experience: TUM exceeds above goals.

What it doesn’t doIt’s important to guarantee performance and reliability, so:

• We don’t support other databases

• We don’t support other user database back-ends, i.e.

• LDAP

• Web services

Integration with outside services, for better or worse, is by copying information.

• No (intrinsic) defense against packet sniffing.

ToolsetBased on market-leading tools for top performance, reliability and maintainability:

•Apache 2 web server

• PHP 4 (transitioning to 5)

• MySQL 4.0 (transitioning to 4.1)

Secondary tools:

• Smarty templating system

• jpGraph (real-time graphing)

Programmers Eye Viewrequire_once “tapir_auth.php”;

$auth=new Tapir_Auth();

// For personalization…

$auth->optional();

// To control access..

$auth->required();

$email=$auth->get_email();

$first_name=$auth->get_first_name();

Authentication Object

$auth->required() and related functions are about 200 lines of code in most languages.

By implementing the ‘Tapir_Auth’ object in a language (say Java, TCL), applications written in that language can use TUM authentication and benefit from the TUM UI written in PHP.

Applications have the full power of SQL to access the user db.

TUM is based on open standards (cookies, SQL) and avoids roach motels (session-variable facilities and proprietary object databases.)

Database accessSupports a single database connection per script, lazy connection creation, interoperation with other MySQL APIs, robust error handling and convenience:

$count=

$auth->conn->select_scalar(

“SELECT COUNT(*) FROM tapir_users”)

Session CookiesBased on “Do’s and Don’ts of Client Authentica-tion on the Web”http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

398927:1:132.236.212.35:1097859122:15:oQjG5oe2T6uMmlvHyS7CnBte/d4

User Id

Session Id

Ip address

Capabilities

Timestamp Cryptographic

Hash

Cookies are reissued when timestamp is > 10 m old. SHA1 hash with secret protects cookie from forgery or alteration.

Other Cookies

tapir_permanent:

Secret token for permanent login like Amazon, Yahoo.

tapir_browser:

Standard cookie issued by Apache’s mod_usertrack to track browsers

If we add SSL support, we’ll also add a tapir_secure cookie that only travels over SSL.

Customization

• A site can provide templates (plain PHP or smarty) for both the user and admin pages

• Namespace conventions allow sites to add own tables and columns to tapir_ tables

• Numerous hooks provided to allow modification of login and registration behavior (can replace forms, talk to external systems, etc.)

• Much of the admin UI is table-driven, much customization is almost trivial.

• Configuration management system lets local sites replace files, and configure PHP, Perl and Apache configuration files with M4 macros

External User Interface

UI: Devil in the Details

• Jacob Nielsen:

• Authentication is a major barrier to usability

• Many processes on commercial web sites have <50% success rate

•With Tivejo, we increased the registration success rate from 60% to 85%, arXiv attains nearly 95%

•Base 32t coding for (e-mail verification, password reset, and other) tokens: 60-bit security in 12 easy-to-type characters, insensitive to case and common errors such as 0/O and 1/L confusion

K8TLTI-78FKTR

Administrative Interface

•Benefits from development for multiple projects

•Tour: (arXiv.org)

• Main screen

• Advanced Search

• User detail screen

• Real-time graphing

UI Toolkit

• Purposely set out NOT to develop a universal framework, BUT

• developing a sophisticated UI that’s consistent and maintainable has required us to develop a framework

• the “update protocol”

• template system

• the “screen” concept

• query builder

• real-time graphing

Case Study: Tivejo

• For a while, Brazil’s #1 voice chat service; 250,000+ users and 300,000 hits per day

• Web site controlled access to a Windows application, interacted with Paltalk.com via a ‘REST’ web service

Tivejo www

Tivejo mail Tivejo db

Paltalk.com

other userbrowser chat client

registers downloads

web service

authentication, call setup

UDP, peer-to-peer, “VoIP”

Case Study: LS Wikis

Wanted a wiki for both public and private documentation – existing wiki software didn’t support authentication.

• Ported TUM to Solaris (install scripts)

• Two wikis:

•funkenstein: open registration

•docs-production: closed registration

• Chose PHP Wiki: Wiki Tiki Tavi

• About an hour to get authentication minimally working.

• Another two days to get everything right

Case Study: arXiv.orgWorld’s largest physics publisher: (also math, cs…)

•293,000+ papers (nearly 200 submissions/day)

•60,000+ registered users

Legacy System:

Perl CGI scripts, using filesystem for paper storage and Berkeley DB for user database. Very messy data, some users aren’t even registered, not possible to determine submitter of all papers

Requirement:

Flexible user database so we can implement “endorsements” to control problem submissions.

Case Study: arXiv.org IIChallenges:

• Implement Perl Auth object for legacy scripts

• Clean up user database as best possible

• Making a complex user interface for endorsement simple for users

• Making it easy for administrators to do routine and not-so-routine jobs

Still to do:

• Move all admin functions to web

• Move e-mail subscriptions to web

• Require Password option, hide .PHP urls, etc.

ConclusionTUM: Best-of-breed user management system, works with (not against) existing applications and mainstream programm-ing methods; incorporates lessons learned from a number of projects; provides the interface that users expect from major commercial sites; convenient to install and administer.

http://www.honeylocust.com/x/products/tum/