't mind anyone seeing. Despite many warts, the public beta version that I tested offered a unique and promising approach to Internet security.
Based on the Kerberos authentication technology, TrustedWeb adds SESAME (Secure European System for Applications in a Multivendor Environment) extensions to provide role-based access control and public-key encryption. Roles typically group users by their work function. TrustedWeb protects Web pages, scripts, downloadable files, and anything else that can be addressed with a URL. Only validated users engaged in an authorized role can access the data.
The TrustedWeb server components run on Solaris and Sinix (Siemens Nixdorf's flavor of Unix); Windows NT support is expected in July. The client runs on 32-bit Windows, Solaris and Sinix; other Unix flavors for both client and server will follow later. I installed the TrustedWeb server on a Solaris box, and the client on a Pentium system running Windows
NT 4.0 with Service Pack 2.
Role-Based Protection
The notion of role-based security isn't new; it's implemented in commercial databases, OSes (including NT), and other secure applications. The theory is wonderfully simple: Organize those who have physical access to your data into groups based on their job descriptions and/or the tasks they perform. For instance, the woman in accounting who handles some basic administrative chores might be assigned the roles "accounting" and "system operator." Roles are usually arranged in hierarchies that make some roles composites of others.
Roles simplify administration. Access rights to files and services are usually assigned on a per-user basis. Adding, removing, and modifying access permissions becomes tedious when you must track individual users. Role-based access is an extension of simple groups; you could build yourself a basic role-based security system on any OS that supports groups--with a couple of twists. Each user is assigned a single defau
lt role, but not all OSes have the notion of a default group. If a user wants to switch to another role, that role can have different attributes associated with it. Its transactions might be more heavily logged, or the user might have to supply a password to switch to that role.
In Operation
One of TrustedWeb's most appealing aspects is that it should seamlessly interoperate with virtually any Web server. TrustedWeb's server components
sit between
users and your Web content; the Domain Security Server sets up a conversation with the TrustedWeb client and determines whether the user is authentic. The Domain Security Server, like the rest of TrustedWeb, takes its data from a configuration file. When the client hands over its authentication data, the Domain Security Server compares that data with the fields in its configuration file until it finds a match.
Once the Domain Security Server authenticates the user, the separate TrustedWeb Server determines whether the user
is allowed to access a particular URL resource. TrustedWeb Server creates proxy connections between clients and one or more Web servers. Configure your Web server to refuse all connections except those that go through the TrustedWeb proxy, and you can secure your content.
Each user has five key properties set in the Domain Security Server's configuration file: domain, user name, default profile, audit identity, and allowed profiles. The domain and user name uniquely identify the user. The default profile names the role the user is assigned if none is requested. Typically, users don't change to a role other than the default.
The audit identity field determines how a user is listed in TrustedWeb's logs. Some users might prefer to use an alias rather than the true user name that's listed in the logs, and usage patterns might be more than some wish to reveal to others. Finally, the allowed profiles provide the names of all roles a user is permitted to take on.
Entries in the TrustedWeb Server's
configuration file use wild-carded URLs to protect hierarchies of Web resources. Each line describes a resource or group of resources and assigns to it an access type of open, entry, or hidden. Open access allows all browsers to access the resource; no authentication is requested or required. Entry access lets all browsers know the page exists on the server, but the content isn't delivered until the user is authenticated. Hidden access lets an unauthenticated user see nothing; even the structure of the content is concealed until the security data is exchanged. For entry and hidden resources, TrustedWeb accepts a list of roles that are permitted access to each resource.
The TrustedWeb client, available for 32-bit Windows, Sinix, and Solaris, links the user's browser with the remote TrustedWeb Domain Security Server and exchanges authentication data. The client runs in the background, separate from the browser. Once a user logs in through the TrustedWeb client, his or her credentials are valid for the rem
ainder of the session or until a configurable time-out expires.
Unlike straight Kerberos, which is strictly for authentication, TrustedWeb supports the negotiation of encrypted channels using the RSA algorithm for public-key encryption. As a non-U.S. company, Siemens Nixdorf is not subject to U.S. export restrictions for cryptography; thus, it can deliver full-strength TrustedWeb internationally.
Miles to Go
TrustedWeb represents a marvelous seed of an idea, but it falls short in its imple-mentation. With its $100-per-registered-user price tag for clients (for up to 500; after that, Siemens Nixdorf will talk site license), even after applying the forgiveness filter common to reviews of beta software, TrustedWeb's basic flaws seriously diminish its appeal.
For example, the product's role structure is too simple to suit most complex organizations. It's flat, except for the domain prefix, which allows you to set up a basic two-level hierarchy. Also, the roles themselves have no propert
ies associated with them. They work too much like groups, delivering the convenience of pooling similar users together, but without the functionality one expects from a true role-based system.
In addition, TrustedWeb's setup and administration are nightmarishly complex. Someone who already understands X.509 certificates and proxy servers will be able to get through it just fine. But if you're a little fuzzy on either of these concepts, expect to be bewildered by the 35 pages of related documentation that accompanies TrustedWeb.
I tested the Solaris version of the TrustedWeb server. Perhaps the NT release will show some improvement in ease of setup and administration. The client, which has no user interface and provides no feedback, was no walk in the park, either. When it didn't work, there wasn't much to go on. The promised appendix covering appropriate registry entries wasn't part of the beta documentation.
Siemens Nixdorf's Web-based administrative interface is shaky in the beta version;
it doesn't commit changes and fails to bring up some pages. But something as convoluted as TrustedWeb needs better graphical administration tools.
In the end, TrustedWeb feels less like a commercial product than an internal hack that the company chose to release. That's no slam--lots of worthwhile solutions started life as internal hacks--but it would be worth hanging back to give Siemens Nixdorf a chance to make TrustedWeb ready for prime time.
At this stage, the package doesn't seem quite ready for an external beta test. I look forward to taking another look at TrustedWeb when it's more mature.
Where to Find
TrustedWeb 1.0 (beta)...................$100
per registered user (up to 500 users)
(client: Windows 95/NT, Solaris; Sinix
server: Solaris, Sinix)
Siemens Nixdorf Information Systems, Ltd.
Dublin, Ireland
Phone: +353 1 676 7551
Internet:
http://www.trustedweb.com
Enter 997 on Inquiry Card.
All the Web's a Stage
