This page is marked obsolete
Contents |
BearBridge - SUNY Potsdam Off-Campus Web Proxy System
Requirements
- Perl 5.004 or better
- Perl Modules available from CPAN
- MD5
- URI::URL
- LibNet
- LibWWW (LWP)
- CGI.pm
- Perl Modules NOT available from CPAN (authored by myself)
- PAM::POP3 or PAM::LDAP
- Apache Web Server (version 1.3.4 or better recommended)
- mod_perl for Apache HIGHLY recommended (version 1.18 or better required, if it is used)
Features
- Modular authentication/security for upgradability
- Ability to deny users (based on username) from using the service
- "Smart" error reporting
- Usable on server arrays/clusters
- User log (who logged in, when and from where)
- Intuitive Administrative Interface for denying users and adding domains or URL's to allow
- Will run under most webservers with little or no changes
- Ready to run under mod_perl for the Apache Web Server
Non-Technical Description
Bear Bridge was designed to provide reliable, high-performance, scalable, and secure off-campus access to web-based services previously only available to the SUNY Potsdam College Community while they are on-campus.
Reliability
Bear Bridge is built upon the latest versions of the most widely used webserver, Apache, and the most widely used CGI language, Perl. These proven leaders in web technology combined with the rock-solid Sun Microsystems UNIX system housing Bear Bridge guarantee performance and usability. The "smart" error system is designed to minimize errors, and provide intuitive error messages in the advent of such errors.
High-Performance
The same components that give the Bear Bridge system its reliability, coupled with the mod_perl module for the Apache web server, also give Bear Bridge the ability to outperform traditional CGI-based proxies.
Bear Bridge works as a functional piece of the webserver, minimizing start-up, request and response times. Benchmark and load testing show Bear Bridge running under mod_perl is approximately 400% faster than a conventional CGI proxy.
Scalability
Bear Bridge is made of three components: the main program, the authentication module, and the administrative interface.
The main program itself provides 99% of the functionality. It is involved in all user interaction, and all actions other than authentication.
The authentication module was designed with the future in mind. Right now, Bear Bridge uses POP3 authentication techniques to verify usernames and passwords with our campus e-mail server. By interchanging modules, nearly any authentication technique can be used including LDAP, Kerberos, SSL, PGP-sign, and others. All of this usability at the expense of changing one line of code in the main program.
The adminstrative interface allows administrators to add URLs to the list of 'acceptable URLs' and also to add usernames to a 'deny list', so that malicious/ unauthorized use can be controlled. The administrative interface is kept separate (software-wise) from Bear Bridge itself, so that it can be installed in locations other than where Bear Bridge resides.
Bear Bridge can also be set up on an array of servers, and fully supports load-balancing and server arrays.
Security
Bear Bridge's security is completely modular. Right now, it uses POP3 authentication techniques to verify usernames and passwords with our campus e-mail server, but nearly any security mechanism can be adopted with little trouble including LDAP, Kerberos, SSL, and more. Bear Bridge security is as good as the source of the authentication.
Order of Things
When someone starts using Bear Bridge, a lot of things start happening.
The first thing that is looked at is the users' IP address. This address is a unique number, assigned to every computer on the Internet by their ISP. Bear Bridge looks at this number to ascertain whether this person is on-campus or off campus. If they are on-campus, Bear Bridge redirects their browser to the URL they want to go to, without using the proxy. At this point, Bear Bridge is out of the picture. If they are off-campus, Bear Bridge continues on.
At this point, Bear Bridge compares the URL they are requesting, to a list of URLs that are "allowed." If a URL is requested that IS NOT "allowed", then Bear Bridge redirects their browser to the URL they want to go to, without using the proxy. At this point, Bear Bridge is out of the picture. If a URL is requested that IS "allowed", then Bear Bridge continues on.
The third phase Bear Bridge goes through is authentication. When a user verifies who they are (currently using their campus e-mail username and password), a "cookie" is stored in their browser. This "cookie" is proof that they've verified who they are, and allows the user to continue using Bear Bridge without having to "log in" again, until they exit their browser. If a user has just begun a session on Bear Bridge, and has not yet verified who they are, then a log on screen appears, and they are asked to enter their username and password.
Before this username and password are even sent to the authentication module for processing, the username is compared against a list of "denied", or "banned" usernames. If they fall into this category, they are informed of this, and are not allowed to use the service.
After passing through the "deny list", usernames and passwords are sent to the authentication module for verification. Currently, Bear Bridge is using our campus POP3 server for authentication. All this means is that the username and password that users use for getting their e-mail, is the same username and password they use for Bear Bridge.
If the users' username and password are confirmed, then the users' browser is given a cookie, and they won't need to log in again until they either close their browser, or their browser crashes. Bear Bridge zips them off to their intended destination, and the rest is history. Of course, if their username/password do not match, then they are presented with a message that says so, and the login screen as well.