Authentication of users is becoming increasingly important as the Web has more and more second generation Web applications. In addition to Web administrators wanting to control access of Web pages, second generation dynamic applications want to control access to Web resources, such as various certain parts of a virtual store. Oracle Corporation has developed a generic authentication mechanism that allows Web administrators and dynamic content providers to control authentication of clients. This mechanism has been implemented on top of CORBA so that the authentication of clients can be distributed across the network, allowing Web-based applications to be extensible and scale across the Internet and Intranet. This mechanism is currently implemented as part of the Oracle Web Application Server, but is generic enough to be used by any application framework.
We are seeing the emergence of second generation Web applications that provide dynamic content back to users. An example of dynamic content is electronic commerce, where users are validated and shown parts of the online store that are applicable to that user. Another example is a subscription service, where the user obtains news stories and other information of interest. These examples require the use of an authentication engine in order to identify and control access to information that is only for that user. Web servers that support these type of applications are called Web Application Servers. This paper discusses a new authentication model, based on distributed computing (via CORBA), that allows for a Web Application Server to distribute authentication requests across the Internet and Intranet. This model is not only distributed, but also extensible and scaleable so that these second generation applications can be developed to provide the next step in Web-based computing.
In this paper, we define authentication terms, and discuss the new authentication model, the distributed aspects of this model, and the clients of this model in the Oracle Web Application Server.
Authentication is a means for the server to restrict access to Web pages. Currently, the HTTP protocol [1] identifies two ways to perform authentication: basic and digest [2]. In basic authentication, the username and password of the user is transmitted from the user-agent to the server. In digest authentication, the user-agent and server perform a challenge and response mechanism that avoids sending the password over the wire. If a Web page is protected, and the user-agent does not supply the correct credentials, then the server must respond with a 401 error code and the appropriate WWW-Authenticate header.
For the basic authentication method, the WWW-Authenticate is given by the rules:
challenge = auth-scheme 1*SP realm *( "," auth_param )
realm = "realm" "=" realm-value
realm-value = quoted-string
For example, the server can send back the following header when a username and password is required:
WWW-Authenticate: Basic realm="WallyWorld"
When the user-agent sees the 401 error code, it must obtain the
username and password of the user. Once this is done, the user-agent
reforms the original request, and adds a new header named Authorization,
as given by the rules:
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64 [7] encoding of user-pass, except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
For example, the user-agent sends the following header for the user "Aladdin" and password "open sesame":
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
If the user-agent knows the username and password, it can send
them in the Authorization header in the original request. In this
way, the user does not have to repeatedly supply the same username
and password.
In the authentication service model, an authentication scheme
is a mechanism by which an entity, such as a user-agent, is authenticated.
Each authentication scheme requires some authentication information
from the user-agent. For example, the basic authentication scheme
requires a username and password, whereas the IP authentication
scheme requires the IP address. The database authentication scheme
also authenticates users using usernames and passwords, but the
passwords are checked against those stored in the Oracle database.
Each authentication scheme is identified by a name which must
be unique. For example, the basic authentication scheme is identified
by the name "Basic".
An authentication realm is a protected region which requires authentication for access. Each authentication realm is identified by a name which must be unique within each authentication scheme. For example, the string "Basic(Admin Server)" refers to the realm "Admin Server" in the basic authentication scheme. For use in the WWW, the server needs to send a 401 error code back to the user-agent and include an appropriate WWW-Authenticate message, including a realm name. This realm name is typically displayed in a dialog box.
The protect string is a combination of authentication schemes and authentication realms, separated by a logical operator. The protect string is used in several places. In the Oracle Web Application Server, there is the concept of a virtual path (or URL [3]) that indicates which static or dynamic page is to be accessed. In addition to the virtual to physical path mapping, each virtual path can be assigned a protect string so that each virtual path requires authorization.
The following is the syntax for protect strings:
Protect string = Scheme-realm *(op Scheme-realm)
Scheme-realm = Scheme-name "(" Realm-name ")"
op = "&" | "|"
Scheme-name = 1*TEXT
Realm-name = 1*TEXT
The '&' and '|' are the logical AND and OR operators respectively.
An example of a protection string is "Basic(Admin Server)
& IP(HQ Hosts)". This string allows users in the "Admin
Server" realm from the basic authentication scheme and machines
in the list of IP addresses in the realm of HQ Hosts from the
IP authentication scheme to access the Web page. This limits access
to users that know a username and password and come from an allowed
IP address.
Figure 1 shows the authentication service model.
An authentication client (or client) is the application that wishes to perform authentication. A HTTP daemon (or listener) would want to authenticate a client if a virtual path is restricted by a protect string. When the daemon receives a request for a Web page, it uses the authentication APIs to authenticate the client.
Clients can be diverse and are not restricted to just the HTTP daemon. Other examples of authentication clients includes electronic commerce, and home shopping, where these Web-based second generation applications are providing dynamic content back to users, based on who the user is and what credentials that user supplies (usually in the form of a username and password). These Web-based applications have also been named cartridges by the Oracle Web Application Server.
When an authentication client requests authentication, the authentication request is dispatched to the authentication broker (or broker) who will perform the authentication and inform the client of the result. The role of the broker is to coordinate the authentication request and to transfer the actual authentication to one or more of the authentication providers. In addition, the broker can cache scheme and realm names and create corresponding IDs for efficiency.
The authentication provider implements the actual authentication. For each scheme, there is one provider, and each provider registers with the broker to indicate which scheme it supports. The broker in turn broadcasts the availability of each scheme to its clients.
When an authentication request is received from a client, the broker routes the request, with the authentication information, to the provider that is responsible for the scheme. It is the responsibility of the provider to authenticate the request. Each provider defines a format for the authentication data that it requires from the clients. The clients pass this information to the broker (in a generic manner), who in turn issue this data to the indicated provider. If the provider determines that the client is not authenticated, the provider has the option of returning some information back to the client. (See the digest authentication scheme description below.)
There are currently a set of five authentication providers. Each of these providers implements a pre-named scheme and is listed below:
In addition to these five pre-defined authentication schemes, developers can easily add new providers (and hence new schemes). There is a standard API that exists between the broker and the provider. Any new providers just need to accept a request for authentication and provide an answer (and potentially any return information back to the client). When a new provider is plugged into this architecture, there is no need for changes to the client software. The only change is to the protect strings, and since those are usually configured by the administrator, only minimal effort is required to develop a new provider.
If the client wants to authenticate a user based on the protect string of "Basic(foo) & IP(HQ Hosts)", then the authentication client issues several APIs to the broker to parse this protect string. The broker then returns the individual components back to the client with an indication of the information that is required by each scheme. In this example, the broker parses this protect string into two separate scheme/realm pairs (one for Basic and one for IP). The client then calls into the broker again, passing the username/password for the basic scheme and the client's IP address for the IP scheme. The broker then issues a call to the basic provider, passing the username and password. At the same time, the broker issues a call to the IP provider, providing the client's IP address.
Next, each provider consults its own configuration to determine if the client should be authenticated and passes back the results to the broker. Finally, the broker combines the results and performs any logical '&' or '|' that are necessary to arrive at a final result which is returned to the client.
There are currently two modes of operation that are supported: in-memory and CORBA. The interface between the authentication clients and the broker and the interface between the broker and individual providers can both be configured for either mode. This gives great flexibility to the administrator in deciding where to place the various pieces of software. There are tradeoffs, discussed below.
The in-memory model uses C for the APIs and IDLs for CORBA. Note, even though providers can be distributed via CORBA, there is an abstraction layer present, so all providers think they are running in the in-memory mode, (via a C API) when in fact they are running as a CORBA object. In addition to applications making use of the authentication model, there is a single C API that is used to access all the APIs in the client. The client translates those to CORBA IDLs if the broker being configured in CORBA mode. The goal is to make the C and the CORBA API as transparent as possible.
Four distinct cases can be configured. In the simplest case, shown
in Figure 2, all modules are using the in-memory mode and are
linked in via C APIs. This model is simple to configure and maximizes
performance, since all modules reside in the same process space
and are accessed by C APIs. The disadvantage here is that each
provider is caching its own copy of the authentication information
(e.g., username and passwords for the basic provider), which means
that more memory is consumed and the solution does not scale well
when there many users. For example if there are ten clients running
with the basic authentication scheme using the in-memory model,
then since all ten clients are linked into the same processes
space, there will be ten sets of authentication data cached, one
for each basic provider. If there are say 10000 users, then this
may consume too much memory and overload the system.
To solve the memory requirements from the first case, providers can be distributed across the network and accessed as CORBA objects as shown in Figure 3. Although getting authentication results is slower, since the broker now needs to access the providers across the network, there is only one copy of the provider running, minimizing memory usage. The decrease in performance might be partially offset by the provider's ability to be closer to the data used for authentication. In the case of the Basic_Oracle provider accessing the database for usernames and passwords, it may be best to place the provider on the same machine as the database itself, reducing the time the provider takes to access the database. There is no requirement that all providers must run on the same platform. It is possible to have one provider running on UNIX and another on Windows/NT.
The distribution of providers gives the broker (working in conjunction with CORBA) a way to provide load balancing and scheduling of authentication requests from clients among a set of providers implementing the same scheme. For example, if there are several basic providers on the network, the broker can determine which basic provider can more quickly satisfy the authentication request.
Since the providers are located on different machines than the client, the client has the potential to do other things while waiting for the authentication results to be returned. When requesting authentication, the client specifies either blocking mode or non-blocking mode. In blocking mode, the client waits for the authentication results from the provider. However, the machine is no longer doing the actual authentication (as was in the first case above), so other processes on that machine are not slowed down by sharing the CPU with the provider. In non-blocking mode, once the provider is contacted, control is returned back to the client so that the client can do other tasks. When the client is ready, it must check to see if the provider is finished. These two models of blocking give the client the most flexibility and are crucial for supporting many diverse client architectures (such as a thin client running on a network computer).
Note, it is still possible to have some providers running in the
in-memory mode and some providers running in CORBA mode, so a
mix of Figures 2 and 3 are possible. Also, some providers can
be located on one machine and other providers can be located on
other machines.
The third case is to move the broker to another machine entirely.
This is useful when the client's machine has limited capabilities,
or does not want to take any additional memory for the broker
itself. This case is shown in Figure 4. The client makes calls
to a stub module, which packages up the request and forwards it
to the broker via CORBA. As in the previous case, the client machine
and the broker machine may be on different platforms.
The last case is shown in Figure 5, in which all parts of the
authentication model are distributed across the network via CORBA.
This provides maximum flexibility, but a corresponding potential
reduction in performance. Just as in Figure 3, it is possible
to have some providers running in the in-memory mode and some
providers running in CORBA mode. Also, some providers can be located
on one machine and other providers can be located on other machines.
This case represents the maximum amount of distribution, and is
also the most complicated architecture to administer.
The benefit of this architecture is that once the clients are implemented, the administrator can decide where to place the clients, broker, and providers. Neither the client nor the provider (or the system administrators for these pieces) need to determine where they should be placed. This decision is left up to the administrator who can decide where to place these pieces according to the system requirements.
The authentication services model described above are currently being used by the Oracle Web Application Server. This Web Server contains three separate clients which are the web listener/dispatcher (HTTP daemon), cartridge-based authentication, and ICX. Each is discussed here.
In the configuration for the Oracle Web Application Server, the administrator specifies the virtual paths allowed as URLs. With each virtual path, there can an associated protect string that specifies the scheme and realms that must be satisfied in order for the server to return the indicated page. Protect strings can be arbitrarily complicated, but typically are just a few schemes as in the example "Basic(foo) & IP(HQ Hosts)". The Oracle Web Application Server is built using a HTTP daemon (listener) independent layer. The generic piece that handles requests is called the dispatcher and currently runs on top of either the Spyglass server or the Netscape Fasttrack server. Since the dispatcher makes calls into the authentication services, the authentication model is the same for any listener.
As the Web matures, the demand for a new breed of Web server products capable of performing transactions and supporting a rich set of applications is high. The Oracle architecture that supports this new breed of products is cartridges. A cartridge is Oracle's dynamic HTML page-generation model, which is analogous to cgi-bin programs. Cartridges can be distributed across the network themselves via CORBA and are called from dispatchers. The lifecycle of a cartridge includes initialization, authentication, execution, restart, and shutdown. These stages are called automatically from the Oracle Web Application Server framework.
The authorization routine is called to allow the cartridge to perform the authorization check, before its execution routine is called to serve the HTTP request. In this callback routine, a cartridge can specify the desired protect string that must be satisfied before control is to be given to the execution stage. The list of authorization schemes is exactly those provided by authorization providers, including basic, digest, IP, domain, and Basic_Oracle. If the client does not pass the authentication (i.e., an authentication provider indicates that the client is not authorized), then the correct WWW-Authenticate message is sent to the client and the execution stage of the cartridge is never called.
In addition to allowing a cartridge developer to specify the protect string that must be specified, the cartridge developer can require authorization based on whatever criteria the developer wants. In this case, the authentication model is not used, but the responsibility of authentication is passed to the cartridge itself. There are some helper routines that send out the correct WWW-Authenticate message. This allows cartridge developers to deploy applications that contain dynamic authentication requirements.
ICX (Inter-Cartridge Communication) is a feature of the Oracle Web Application Server that allows a cartridge to send an HTTP message to another cartridge. The first cartridge may need the results from a second cartridge, and when those results are received, the first cartridge sends back a combined HTML response to the client. For example, a cartridge that implements a virtual bookstore can use ICX to talk to another cartridge that processes a payment request to debit the users account. Since ICX makes an HTTP request from one cartridge to another, the first cartridge must have all the authentication information needed in order to talk to the second cartridge. There are a set of ICX APIs that the first cartridge invokes to set the username and password used in authenticating to the second cartridge.
In the Oracle Web Application Server, cartridges themselves can be distributed across the network via CORBA. When the ICX module receives the request from the first cartridge to talk to the second cartridge, a check is made to determine if the second cartridge is in the same ORB system as the first cartridge. If not, then ICX behaves just like a browser and sends the appropriate HTTP request on the wire, with the proper Authenticate header. The dispatcher, when receiving this HTTP request, does not know if the request came from a user-agent or from ICX and it does any necessary authentication.
However, if ICX determines that the second cartridge is in the
same ORB system, then there is no need to send an HTTP request.
Instead, ICX calls the cartridge's execution stage directly (via
CORBA). In this case, since there is no HTTP daemon (and hence
no dispatcher-based authentication), there is no authentication
performed on the machine where the second cartridge is running.
In this case, ICX calls the authentication API directly to verify
that the first cartridge can indeed invoke the second cartridge.
As more companies develop second generation Web applications to
provide dynamic content back to users, the need for authentication
becomes more important. This paper discussed a new authentication
model that supports these Web applications in the context of a
Web application server This model is distributed, extensible,
and scaleable so that these second generation applications can
be developed to provide the next step in Web-based computing.
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, HTTP Working Group, Internet Draft (August 1996).
[2] John Franks, Philip Hallam-Baker, Jeffery L. Hostetler, Paul Leach, Ari Luotonen, Eric W. Sink, Lawrence C. Stewart, An Extension to HTTP : Digest Access Authentication, HTTP Working Group, Internet Draft (September 1996).
[3] T. Berners-Lee, L. Masinter, M. McCahill,
RFC 1738: Uniform Resource Locators (URL) (December 1994).