Tapir User Manager

1. Tapir User Manager Paul Houle, Library Systems, CU Library http://www.honeylocust.com/x/products/tum/ Ph18@cornell.edu

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

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

4. Web Portals • A 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.

5. The web software crisis • Two 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…

6. Performance Goals • Appropriate 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.

7. What it doesn’t do • It’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.

8. Toolset • Based 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)

9. Programmers Eye View require_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();

10. 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.)

11. Database access Supports 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”)

12. Session Cookies Based 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 Session Id Ip address Capabilities Timestamp Cryptographic Hash User Id Cookies are reissued when timestamp is > 10 m old. SHA1 hash with secret protects cookie from forgery or alteration.

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

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

15. External User Interface

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

17. Administrative Interface • Benefits from development for multiple projects • Tour: (arXiv.org) • Main screen • Advanced Search • User detail screen • Real-time graphing

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

19. 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 UDP, peer-to-peer, “VoIP” browser chat client other user authentication, call setup registers downloads web service Tivejo www Paltalk.com Tivejo mail Tivejo db

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

21. Case Study: arXiv.org • World’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.

22. Case Study: arXiv.org II • Challenges: • 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.

23. Conclusion TUM: 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/