 |
|
|
Table of Contents Introduction An ever increasing volume of business is being conducted on-line these days. Whether it is designated as business-to-business (B2B) or business-to-consumer (B2C), companies are using the Internet to conduct electronic commerce, and to exchange information electronically, to a far greater extent than ever before. To support this, web-based and portal-enabled applications are required in order to provide the electronic equivalents of the more traditional business processes such as retail, customer service, and transactional data processing systems. Suddenly, the idea of �keeping people out� of our computer systems has been replaced with the almost direct opposite requirement to �welcome them in�. Well, not welcome them in exactly � certainly not to our internal computer systems. But we do need to be able to provide access to more information than ever before � customer data, order details, inventory information, and so on � so that our eBusiness can be performed in a more streamlined and well integrated fashion. The number of users and business partners that visit corporate portal sites to access and retrieve this information can be enormous, exposing web sites, valuable corporate information, mission-critical business applications, and consumers� private information to increased risks. This approach thus presents a number of significant new challenges to the system or security administrator: Managing users - Since vast numbers of users can access and retrieve information from web sites, a highly scalable database and transaction engine is required to handle the volume with acceptable performance. Controlling access to multiple applications and resources - A good web site ties together many different applications and resources operating in heterogeneous environments with different levels of security needs. The task of controlling access to these applications and resources is critical and must be done in a way that minimises administrative overhead. Personalising the web experience � Every customer that accesses a corporate web site needs to feel individual � just as though they were still being dealt with personally. It is therefore essential that specific web content be displayed based on an individual�s or group�s particular profile. Streamlining the logon process - Users are irritated by logging on every time they begin to use a new application or access a new resource. Irritated users are unlikely to be satisfied or repeat users. Even if they are willing to repeatedly enter their name and password, the re-notification of forgotten and lost passwords can be an administrative nightmare. Maintaining the best possible user experience while maintaining security is crucial to the success of the web operating environment. When the Internet first became popular, early web servers just accepted requests for information and acted on those requests. They knew how to find a linked page and deliver that page. As this magic became commonplace, browsers became more sophisticated and added new features like animated GIFs and Java applet execution. As browser and network technology improved, business uses increased until it became apparent that some form of access control was necessary to limit the exposure of sensitive corporate data to unwarranted browsing. The concept of web access control is based on the principle of monitoring and reacting to HTTP traffic that usually passes through port 80 of a web server. When the web server receives a request, it interprets the header attached to each request and acts accordingly. For instance, if the request is for a computer resource, the access rights of the current user are checked to verify that this person is allowed to access the requested resource. If access is allowed, the resource is passed to the user�s browser as normal. eTrust Web Access Control (Web AC) provides this level of eBusiness portal security combined with a wide range of strong authentication and authorisation methods. In addition, eTrust Web AC provides dynamic personalisation technology based on managed user IDs and roles. Portal access is controlled according to security policies defined by the administrator. Centralised administration, embedded X.500 Directory services � including an LDAP interface � and native Public Key Infrastructure (PKI) support all enable eTrust Web AC to provide a secure and scalable security platform for eBusiness applications. eTrust Web AC offers a number of useful features, including:
eTrust Web AC consists of the following components: The Policy Server resides on a UNIX, Windows NT, or Windows 2000 host and is the central component of eTrust Web AC, providing user authentication and resource authorisation. The Policy Server provides a secure mechanism for managing data in the data stores, as well as authentication, authorisation, and auditing services to the Web and Application Agents. The Policy Server performs the following main functions:
All of the data that eTrust Web AC needs is stored in either the policy data store or the user data store. The policy data store holds all of the information about resources, applications, and policy rules for handling logins and authentication. The user data store can be located either on the Policy Server or on a remote machine. The user data store holds all of the information about users, groups, and login data (user IDs and passwords). If an organisation has already deployed an LDAP-compliant directory as a central user data store, then the eTrust Web AC Policy Server can use the same data store (and actually the same user records). There is no need to deploy a separate user data store. Agents are the mediators between the end user and all web resources and applications. Agents intercept requests made by users, and then interact with the Policy Server to determine whether a user has the proper authority to access the resources that have been requested. There are three types of agents:
The Policy Manager is a Windows-based GUI used by the administrator to manage eTrust Web AC services, agents, and data stores. All communication between the Policy Server and the other eTrust Web AC components is encrypted over TCP using Triple DES encryption, and all accesses and updates made to the Policy Server are captured in the audit trail. eTrust Web AC can also be controlled via a command line language known as selang. Selang can be used to manage both the policy data store and the user data store if the latter is an eTrust Access Control database, and its main uses are in the initial stages of eTrust Web AC implementation, and for batch operations. At the initial point of entry, employees, business partners, customers, and the casual web surfer can request access to resources through the Internet, intranet, or extranet using their browsers. The Web Agent intercepts all inbound traffic to the web server and checks with the Policy Server to determine if that resource is protected. If the request is for an unprotected resource it is passed directly to the web server to be returned to the user as normal. If the resource is protected, however, and authentication is required for this user, the Web Agent first checks to see if the user has been previously authenticated. This check is performed by looking for a valid eTrust Web AC security token stored as a cookie in the user�s web browser. If a valid security token is not found, the agent checks for the existence of the user in the User Data Store and determines the allowed authentication technique associated with that entry (SSO, LDAP, NT, SecurID, or X.509 certificate). It then issues the appropriate challenge:
The Web Agent then takes the security token and stores it as an encrypted cookie in either the browser�s private runtime memory space or in a file. This prevents other users from copying and using a user�s credential information to impersonate the authenticated user. Clearly, there is some activity between the Web Agent and the Policy Server each time a resource is requested by a user. Although the encrypted session cookie minimises the authentication overhead for protected resources, there is still the requirement to determine whether or not a resource is protected before the request can be passed to the web server. In testing, we noted a 20-30 per cent performance penalty between a �vanilla� IIS server and the same server with Web Agent installed. It should be noted that these tests were performed with beta software and further code optimisation may take place before the product is released. Once the user�s identity is verified through authentication and the user has received a valid security token, eTrust Web AC verifies which resources the user is authorised to use. The Web Agent monitors access requests and either performs the desired level of authorisation or asks the Policy Server for an authorisation decision. This authorisation is provided at both the URL and application level. At the URL level, the Web Agent monitors all requests for web page or page component access. After the user has been authenticated, subsequent web site accesses are implicitly authorised, explicitly authorised, or explicitly not authorised. This type of authorisation checking is performed by the Web Agent, which intercepts the requested URL at the web server and checks with the Policy Server to see whether the user identified by the currently active security token is authorised to access the resource. If access is authorised, the resource access is permitted, otherwise access is denied. At the application level, the Application Server Agent checks access rights for each servlet, servlet file, JavaServer Page, Enterprise JavaBean, ASP, or ActiveX object using the authorisation API supplied by eTrust Web AC. This gives the application security designer complete control over what objects are protected and how they are protected. For each protected object, an access authorisation check is performed back to the policy data store to determine whether or not the accessing user has access. An application environment can use either native J2EE components, Microsoft DNA, or another packaged runtime environment to support the execution of site-specific applications. In this case, the authorisation checking is not available at the web server level and must be moved back into the actual application. Despite the complexity of the product, installation is very straightforward. The first task is to install the Policy Server, which also installs the underlying Ingres database, and the Policy Manager. Following that, you then install Web or Application Server Agents on each server where resources are to be protected by eTrust Web AC. Note that there is no automated distribution or installation mechanism for Web Agents, and nor does there appear to be any means to create a �silent install� package. Thus it is necessary to physically visit each server upon which you need to install the Web Agent software. Depending on requirements, it is possible to configure multiple hosts with multiple Policy Servers and multiple user data stores. Policy Servers can then be grouped together into server farms in order to improve performance and resilience. When a number of Policy Servers are installed at a site, they can be configured for replication, thus eliminating the requirement to maintain each data store separately. This configuration is referred to as a server farm. Each Policy Server can serve as a backup for all of the other Policy Servers in a server farm. When the replication mechanism is configured and running, all Policy Servers using it will simultaneously update the local database and all of the databases of the other Policy Servers in the replication group. In this way, the policy data stores on all of the server hosts contain exact copies of all of the eTrust Access Control data maintained in the organisation. Load balancing � for increased performance in large or busy web sites � is also a feature of Web AC server farms. Once the required components have been installed, the administrator must choose the resources and applications to be protected and define them in the policy data store, along with the appropriate rules to protect them. Access to all resources is unrestricted until these definitions are created. Both the Policy Manager and the selang command language can be used to enter this information, and it is also possible to create a list of freely available resources that do not need protection.
The main window of the Policy Manager is divided into five areas:
For those who would prefer not to enter data �long hand� into the Policy Manager screens, a number of Access Control Wizards are provided to ease most of the common data entry tasks.
Out of the box, eTrust Web AC supports the following types of repositories for user data:
eTrust Web AC calls each of these repositories a user data store. A user data store contains definitions of users, user groups, and login data (user IDs and passwords). It is possible to define and use more than one type of user data store in your eTrust Web AC system, and Web AC is capable of using existing OS-specific user data stores (such as Microsoft�s Active Directory) either directly or as a means of populating the EAC database automatically via the import wizard.
User and group definitions contain critical attributes such as user credentials, password policy, login information, and so on. Once the user data store contains the user and group definitions, eTrust Web AC can begin to provide its functionality to end users. Many pre-defined attributes are provided in the default schema, and it is possible for the administrator to define as many custom attributes as required. Any combination of these attributes can later be used to define access control rights, thus making control very granular � for example, you could specify that all members of a given department could have read access to a range of URLs, but that only employees with a certain job title are allowed to update them. One example demonstrated in the sample web site provided with the product is of a user attribute called �Card Type�. This can have a value of Gold or Silver assigned to it, and the sample applications have been written to take account of this, presenting different options to Gold card holders than to Silver card holders.
In Figure 4, we see that a Gold card holder has authenticated to the system and has been presented with a button labelled �Special Promotions For Gold Card Holders�. In addition, the application menu on the left has also been augmented, adding the �Dinner Reservation Network� option which is not available to Silver card holders. Although this obviously requires programming effort (unlike the act of simply protecting basic resources, which is automatic once the ACLs have been created), it is an extremely powerful feature of Web AC allowing for the extensive personalisation of the browsing experience for individual users or groups of users. After users, the other key components in Web AC policies are resources. Resources are grouped into the following categories:
The first task is to define all terminals (workstations) which will be used to administer eTrust Web AC, and all the authentication hosts that will be used to perform basic authentication of eTrust Web AC users.
To protect a resource � such as Enterprise Java Beans, file servlets, Java applets, URLs, and so on � it must first be defined in the policy data store. Protection means that to access the resource the user must have a valid security token and permission to access the resource. If there is no valid security token, the Web Agent prompts the user to authenticate and a security token is created. The user will then be allowed or denied access to the application according to the definitions in the policy data store. Unlike other resources, applications have user name and password information and an HTML script associated with them. This allows Web AC to supply the user names and passwords and automate the login process for the applications. The HTML file contains a JavaScript piece that handles and automates login to the web-based application. Authorised users can access the applications using a personalised application list which is displayed in their browser window (see Figure 4). Access rules define the access permissions for a particular resource and determine what action can be performed on it. The Policy Server allows the administrator to define access rules for all applications and web sites within an organisation, making it easier to manage and control user operations. A rule is composed of a resource, user or group, attribute, and access permission. Access rules govern how an individual can use a particular resource. The rule can allow no access to the resource, or one or more different types of access. For example, an access rule can:
Default access permissions control how a resource can be accessed by those who do not appear in the resource�s Access Control List (ACL). The ACL specifies what access permissions each user has for the resource. The types of access permissions that can be granted to a user depend on the class of resource, since the type of access available for each resource varies. For example, applications use the access types EXECUTE and NONE, but generally do not use READ and WRITE access.
eTrust Web AC provides the following predefined classes (it is also possible to define custom classes):
Groups can be used to simplify the application of ACLs to large numbers of users. Where member and group rights are in conflict, member rights always take precedence, allowing an administrator to apply �blanket� rights for a group and then override certain rights on a per-user basis. Once the policy data store contains the required resource definitions and access rules, eTrust Web AC can begin to provide access control for your resources. One of the nicest features of Web AC is that as soon as the resource definitions are in place, the basic protection offered by the Web Agent is completely automatic � no programming effort at either the client or the web server is required. If replication has been configured for a server farm, then policy data stores on different servers in the farm are synchronised automatically. Applications are resources in the policy data store. Every application that should be accessed through eTrust Web AC must be defined in the APPL class in the policy data store. Since a large company may have hundreds of applications, the applications can be arranged into groups to ease administration. The application record contains information that is used when displaying the application on the user�s workstation and when logging the user in to the application. This information is provided when defining or updating an application record, and is divided into two categories. The first covers details needed when displaying the application to the user, including on-screen captions, contained applications, and so on. The second covers details required by the user to log in to the application, including the name of the login script file, the type of login, and the name of the application host, amongst others. Applications can be designated as common � where all users have unrestricted access � or restricted, where it is possible to hide an application (where it is still available but does not appear on menus), temporarily disable an application (to perform maintenance or upgrades, for example), or restrict use of an application to certain users at certain times of the day or days of the week. Wherever an application is made available to a user, it will appear automatically on the application list menu bar within the Web browser (see Figure 7). Special applications can also be created to simplify administration. A master application, for example, is one that supplies an authentication method and password to other applications. A �dummy� master application could be created as a hidden application, its only role to provide logon information for the applications beneath it. A container application, on the other hand, usually has no logon information associated with it. Instead, it is used as a visual placeholder, allowing the administrator to create sub-menus of applications in the application list menu (see Figure 7).
Applications may also be designated as sensitive, thus forcing users to re-authenticate at more frequent intervals than the default eight hours. Each application can have a script associated with it, allowing users to enter third party or affiliated web sites without having to re-enter login information. When a user tries to access a web site that has been defined in the policy data store as accessible using a script, a request is sent to the Policy Server. The Policy Server sends the appropriate script with the user�s credentials � login name and password � to the user�s browser. The browser then automatically executes the script allowing the user to enter the site without re-entering a login name and password. If the Policy Server does not have the user�s credentials, when the Policy Server sends the script to the browser it executes the learn mode. In learn mode the user enters the credentials and these are sent back to the Policy Server (in an encrypted format) and saved. A Web Agent is installed on each of the web servers that host the web sites to be protected. Once the Web Agent has been installed, it is necessary to define the resources and applications, and the access rules that protect them, in the policy data store. Until these definitions are created, the Web Agent grants all requests. Once configured, Web Agents enforce access control policy, authentication, and directory connectivity. The Web Agent intercepts any request to access a resource and interacts with the Policy Server to authenticate the user and determine if access to the specific resource should be allowed.
The Web Agent also passes a response to the application through the web server that allows personalising page content to the needs and entitlements of each user. When a user tries to access a resource that is not defined as protected, access is granted without going through the authorisation process. If the resource is not protected, the request is passed through to the web server for regular processing. Once Web AC has been installed, the web server that hosts the web site requested by the user cannot send information to the user unless the Web Agent permits it. However, once the Web Agent permits the user access to one resource, the user�s login to additional web resources and applications are handled by the Web Agent without requiring the user to enter user ID and password information again. Every request by the user for additional web resources is evaluated by the Web Agent to see if the user has authorisation to access that additional resource � the ultimate aim is Single Sign On, and Web CA does an excellent job. Many eBusiness portals require that users have the ability to register themselves to the site, since a level of immediacy is often required that would disappear if administrative intervention were required in the user registration process. Web AC provides the means for users to enter their own details into the user data store, and then be assigned privileges and entitlements based on their roles and group memberships. Clearly such a process would have to be controlled carefully, but Web AC provides the means to differentiate between, say, an external casual user who would be provided with minimal access, and members of a closed user group � perhaps employees located at remote branch offices � who would be offered more extensive access based on supplied credentials such as an employee ID number. This ability, called self-registration, means that users of a web site can add their authentication credentials to a specific application without help from the hosting organisation�s personnel. Once those users have registered, they are identified as members � simplifying their login and making their access to resources more efficient. As a result, self-registration allows large numbers of users to register easily, and reduces the cost and effort involved in managing large user populations. The Web Agent supports self-registration by allowing users to enter private information in a dialogue designed specifically for this purpose. After the user completes the registration form, the browser sends the information to the web server on which the Web Agent is installed. The Web Agent sends the information to the Policy Server for verification and storage in the policy data store. Since the user no longer has to repeat this information each time he logs in to a resource, access to the resource is more efficient. Application Server Agents run on application servers under operating systems such as Windows NT, Windows 2000, and UNIX. Operating in a similar manner to Web Agents, the Application Server Agent intercepts application calls and sends API authorisation requests to the Policy Server and authorises access to applications according to the API�s response. eTrust Web Access Control Application Server Agents are provided for the following application servers:
eTrust Web AC provides the ability t configure the audit output that is generated on a per-resource basis (i.e. audit successful and/or failed accesses to a specific application), and then specify where the output should be sent.
eTrust Web AC supports several destinations for audit output:
Unfortunately, there is no built in reporting tool, which is a serious omission in a product of this nature. Without add-ons from CA or third parties it would be almost impossible to monitor effectively the various Event Logs or log files that would be populated by a large, distributed implementation of Web AC. We feel that at least some basic form of audit reporting tool should be included with the product. In the absence of such tools, however, eTrust Audit would be the most obvious choice should budgets allow. This product is designed to collect enterprise-wide security and system audit data from a wide spectrum of sources including UNIX, Windows NT and 2000, Web servers, other eTrust products, mainframe systems, and multiple RDBMS�. eTrust Audit filters collected information for consolidated viewing and reporting, stores this information in a central database for easy access and reporting, and automatically triggers appropriate actions upon detecting unusual or malicious activities on the system. The main features include:
Documentation is adequate (provided in PDF format only), and we found the Getting Started Guide in particular to be quite useful in describing how to get up and running with the sample Web site, talking you through making changes to key parameters and observing the effects. However, we found that the Admin Guide was less useful. It spends a significant amount of time discussing screen shots and describing individual fields without actually providing details of how those fields should be completed. Instead, it points you to the on-line help, which offers slightly more information, but is not context sensitive. Perhaps there is room for another manual here, one which provides some common scenarios (more advanced than those in the Getting Started Guide) and offers suggestions as to which resources and attributes should be created or amended in order to achieve the required results. eTrust Web Access Control is a very flexible and complex product, and more effort needs to be put into the documentation to enable administrators to use the product quickly whilst having the confidence that they are not going to bring a critical eCommerce application grinding to a halt through the over-zealous and misplaced use of access controls. Web AC is one of those products that is difficult to evaluate in a short space of time, since it provides such a wealth of features and flexibility that it is hard to do anything other than scratch the surface. We found the user interface to be intuitive and easy to use, but the sheer scope of the product left us bewildered on several occasions, and with little help forthcoming from the documentation. This should not be regarded as too harsh a criticism, however, since with a product as critical as this one once deployed, the last thing you need is a lack of flexibility. Here, Web CA certainly does not disappoint, providing numerous means of authenticating and authorising users accessing your Web applications. The range of built-in support for the various authentication mechanisms � including PKI solutions � is to be commended, as is the support for data repositories other than the included eTrust Directory, and the extent to which it achieves its goal of single sign on in large-scale distributed and heterogeneous environments. There is certainly a performance penalty that has to be taken into account once Web Agent is deployed on your Web servers, but it is impossible to achieve this level of security without some sort of trade-off in performance and/or convenience. Overall, however, eTrust Web Access Control does an excellent job, and thus earns the �NSS Approved� award. |
Security Testing |
Send mail to webmaster
with questions or
|
