Apache opportunity..

Date view Thread view Subject view Author view

From: Rodent of Unusual Size (Ken.Coar@Golux.Com)
Date: Fri Feb 25 2000 - 12:40:01 PST

If you're interested, contact "Steve McDonald" <steve@execr.com>.
Be sure to mention my name. :-)

An Internet Startup is looking for a software engineer who wants
to be part of creating the best extranet solutions and products
in the industry. You will be responsible for the UNIX
components of <the product>. Working as part of the product team,
you will develop and enhance existing cross platform components
that will be shared between the Windows NT and UNIX/Linux products.
Coordination with the development lead and program manager will
be required for creating schedules and deliverables to QA. Network
programming at the Berkeley sockets layer within a threading
architecture is required.
o Previous experience developing and/or debugging Apache modules. 
o Minimum of 4 years commercial development experience on one or
  more UNIX operating system platform.
o Minimum of 1 year of TCP/IP Berkeley sockets programming on UNIX. 
o Commercial development experience building cross-platform (UNIX
  and Windows) products. 
o Hands on development experience with UNIX Daemons, threading,
  IPC's and UNIX security. 
o In depth knowledge of the HTTP protocol, SSL, XML. 
o Understanding of basic network security techniques and firewalls
  is required. 
o In depth knowledge of Internet proxies and caching algorithms. 
o Hands on development experience with GNU tools, toolkits, autoconf
  and libtool is a plus. 
o Use of RCS, SCCS or CVS for source ccode configuration is a plus.

This company is going to go IPO Middle of Q3 early Q4 at the latest. Clients include half of the fortune 10, bear stearns, Morgan Stanley, E-Trade, Kodak, and IBM. Over 300 enterprise companies. What is it?

<the product> is an HTTP/HTTPS-based reverse proxy that brokers all communication with downstream servers. It enables Web resources to be controlled down to any URL-definable object, such as a JPEG or a GIF file, and provides caching. <the product> uses standard ciphers such as DES, Triple DES, and RC4 for all data encryption, and it supports many authentication types, including challenge-response and client certificates, and other back-end authentication systems. <the product> also supports leading LDAP directories.

To build <the product>, the company uses several Free Software components, most notably Apache, mod_ssl, OpenSSL, and the Mozilla LDAP SDK. In the future, <the product> components will hopefully (this isn't something we can promise unfortunately) become Free Software, and any improvements to these code bases is encouraged. <The company> has already made available code that allows mod_ssl to verify client certificates against an LDAP database.

How does it work?

Typically, <the product> sits behind a firewall at the network perimeter as a "public server" and proxies content from "private servers" that sit on the internal network. <the product> Server hides these private web servers behind an alias, much like Apache's ProxyPassReverse directive. To request a resource, the user enters or clicks on a URL that both points to <the product> and contains an alias. This alias tells <the product> which private server the request should be proxied to. When the resource is retrieved, the URL still shows the "public" address so that the user never sees the internal network's naming scheme.

Authentication is a critical component to <the product>. Administrators create policies that dictate how users should authenticate based on the resources they request or on the networks they are from. They also create policies that enable users to access certain parts of the internal network but not other parts based on criteria such as network they are from or the time of day.

<the product> includes an authentication server that can leverage against a wide variety of backends, including challenge-response backends. Users are prompted for credentials via forms (<the product> does not use Basic or Digest authentication). A separate authentication server is required because its modules, which somewhat resemble PAM, are also used by the SOCKS server and require authentication to occur over a persistent connection. <the product> maintains a "session" via SSL session IDs or cookies. A separate Management Server allows remote administration via a Qt based client.

The company can deploy, and manage if desired, an extranet using <the product> or the company's SOCKS proxy, <another product>.

Where is it going?

Future enhancements to <the product> include: * Adding an Apache 2.0 port. * Open participation in Apache 2.0 development, especially proxy and cache improvements. There is also interest in i18n work. * Greatly improving Apache's cache. * Improving <the product>'s HTML and JavaScript parsing. * Extending <the product>'s parsing capabilities to include other document types such as XML, envisioning <the product> as "the" security policy enforcement point for DAV deployments. This requires that access control lists (ACLs) include HTTP methods. * Clustering or sharing user session data across multiple <the product> servers. * More personalization. * Authentication improvements. * Performance optimizations such as an optimized GNU/Linux or FreeBSD version. * Management and accounting improvements such as SNMP support. -- #ken P-)}

Ken Coar <http://Golux.Com/coar/> Apache Software Foundation <http://www.apache.org/> "Apache Server for Dummies" <http://Apache-Server.Com/>

Come to the first official Apache Software Foundation Conference! <http://ApacheCon.Com/>

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 12:43:13 PST