If you have Web applications that require
user authentication and would like to use the same credentials
that are used for other applications on the workstation and/or
the credentials obtained during workstation logon, then the
TrustBroker™ WebAccess product may
be the product you require.
Overview
Components
The TrustBroker™
WebAccess product provides Kerberos authentication
services between workstations running a Web browser and Web
servers, or Web proxy servers accessible across the network.
If used in conjunction with the WebAccess
Application Server Option the authenticated identity of
the user at the workstation can also be securely presented
to JAVA servlets running on the Application Server.
Typical
Usage
A typical use of this product consists of
the following events :
A user authenticates themselves when they login to their
workstation, or perhaps when they execute a Kerberos enabled
application that performs the user authentication, instead
of (or as well as) during the workstation login.
The user can the use any Kerberos enabled application
which uses the credentials already obtained to present their
identity securely across the network.
The user can use Internet Explorer to access Web content,
or use an application that has an embedded Internet Explorer
interface.
The WebAccess product securely presents the users credentials
(obtained in step 1) to the Web server or Web proxy server
so that the server can use their identity for access control
and/or entitlement purposes. The WebAccess product is used
for authentication purposes only. We recommend that you
use your preferred Web entitlement product, or functionality
in your Web server for authorisation and access control.
Two components are provided
with WebAccess :
Workstation
Web Server
Workstation
The WebAccess product includes a Windows
workstation based interface component (implemented as a COM
Object / ActiveX control) that provides a programmatic or
user based interface to Internet Explorer. The product also
includes a plugin for Internet Explorer (implemented
as a Browser Help Object) so that secure authenticated sessions
with Web servers or Web proxy servers can be used with Internet
Explorer launched from the Windows start menu, desktop or
task bar.
The user of the browser will not notice
any difference when they are browsing, and when a WebAccess
enabled Web server or Web proxy server responds with a message
asking for authentication information (e.g. a HTTP 401) the
browser automatically establishes a security context unique
to the server sending the request and this context is accepted
by the server and actioned accordingly.
Internet Explorer, Version 5.5 (or later)
is currently supported on Microsoft® Windows® 95,
98, NT, 2000 or XP
Web
Server
A WebAccess component is included for installation
on IBM's HTTP Server or Apache.
This component handles the authentication requests from browsers
on workstations by accepting the security context transmitted
in the HTTP header, or determining the users context if they
have already successfully authenticated during a previous
session. Once the context is accepted the Web server or Web
proxy server is able to determine the Kerberos principal name
of the user at the browser so that entitlement decisions can
be made, either to return the page being requested, reject
the request, or to forward the request onto an Application
Server servlet (when using the optional add-on WebAccess
Application Server Option).
IBM HTTP Server or Apache, Version 1.3.x
or 2.0.x is currently supported on Microsoft® Windows
2000 or NT servers.
How
WebAccess improves security
A typical Web application
implemented today, either on an intranet or accessible over
the Internet involves a user authentication approach, similar
to the following :
The user first accesses an application by entering a URL
request into their browser.
The Web server asks the user to enter their username and
password, usually using a form, or sometimes a pop-up authentication
dialog box.
Using the username and password entered, the Web server
is able to authenticate the user by making a lookup in a
database, table or LDAP accessible directory.
To ensure that the password being entered by the user
is not visible whilst traveling across the network a server
SSL certificate is often used for data privacy between the
browser and Web server.
Sometimes user certificates are used to authenticate users
to Web applications - this approach has the advantage that
digital signatures can be used to electronically sign information
on behalf of the user at the browser. The users certificate
and keys are stored in the browser, or on a smart card.
A domain cookie is often used to maintain a session context
for a particular user's access to a Web server so they don't
have to re-authenticate for each URL accessed in the same
domain.
Once the Web server determines the identity of the user
at the browser it is able to use this to determine their
access rights or entitlement, however it is not easy for
the Web server to securely access other tiers across the
network on behalf of the user in a multi-tier application
architecture. Instead, it is common for a stored copy of
the users password, or a common username/password to be
used, which is passed across the network to authenticate
access to other application tiers (i.e. a database requiring
authentication of the user to determine access rights).
The above approach has a number of weaknesses
related to security. Some of these weakness are described
below along with an explanation of how WebAccess improves
the security.
Typical
approach to Web security
When
using TrustBroker™ WebAccess
Since the password has
to be stored somewhere (i.e. a database, table, LDAP directory)
so that it can be checked by the Web server, it has to
be transmitted across the network from the browser.
When using WebAccess the
users password is never transmitted,
even in encrypted form, and is never stored anywhere.
There is often no way
to determine that the Web server is actually the correct
Web server since the authentication is only one way -
the user is identifying themselves securely to the Web
server and not vica versa. The user could be entering
their password and other confidential information over
an un trusted communications channel and it could be captured
by a program (for later use) before being passed to the
actual requested Web server. This attack is commonly referred
to as a "man-in-middle" attack.
When using WebAccess the
authentication between the browser/workstation and the
Web server or Web proxy server is mutual,
so that the server trusts who the user is, and the users
browser is able to trust the identity of the server.
Once the password is used
by the Web server to authenticate the user, there is a
danger that either the password received from the browser,
or the stored password it is being compared with can be
used again by a potential hacker to access the application
on behalf of the user.
The WebAccess product
does not require any password checking or storage on the
Web server, so the potential threat of password
theft is illiminated.
There is no integration
with existing authentication that has occurred on the
workstation before the browser is launched - the user
typically authenticates themselves when they login to
the network, so why ask them to authenticate again, perhaps
using a different username and password ?
With WebAccess the Kerberos
protocol can be used to authenticate the user when they
login to the Windows domain and the same credentials obtained
during this login can be used by the browser to present
a security context to the Web server or Web proxy server
- the user only needs to authenticate once
when they login to the workstation.
When using SSL with user
certificates to give mutual authentication between the
browser and the Web server additional hardware (smart
card readers) will be required to store the user certificate
and keys securely.
With WebAccess the mutual
authentication is achieved without the need for additional
investment in hardware such as smart card readers, however
it is possible (but optional) to authenticate a user when
using WebAccess with two-factor authentication
devices such as token cards (RSA SecurID®,
VASCO Data Security Digipass™ or Secure Computing
SafeWord™) or smart cards. Also, regardless of the
user authentication method used the Web server code and
application code stays the same.
Cookies can be vulnerable
to theft and man-in-middle attacks
The WebAccess product
does not use cookies to maintain a user context.
Downloads
& Documentation
To download a data sheet that describes
the WebAccess product click here
(359kb)
You will need Adobe Acrobat Reader to view this file after
download.
You can order the installation and administration
guide for this product by clicking the link below :
Future
Plans & Making Contact
In future versions of this product support
for additional Web servers, operating systems and browsers
are being considered. We would like to develop new features
into this product based on market needs, so if you
don't see your exact requirements described please
don't let this stop you from making contact with us.
Contact
Us
If
you have specific Web authentication requirements that
you would like to discuss with us please provide us
with your details by clicking here
and we will be happy to discuss how WebAccess or WebAccess
with the Application Server Option might be able to
meet your requirements.
.jpg)
