With its easy-to-perform installation and configuration, as well as a solid Web-based management interface, getAccess is comparable with SelectAccess in many ways. All looked rosy for this package until we tested its performance under heavy load. At that point, the glow faded.
GetAccess has a two-part installation process: the application server installation and the Web server plug-in installation. The two steps seemed simple in our initial tests, but the getAccess installation became a little shaky when we tried to tie the back-end application to our existing Netscape LDAP 4.12 server. Entrust documentation confirmed that this problem occurs with 4.12 and higher. To overcome this snag, we installed Netscape Directory Server 4.11 on our product server and performed a complete Entrust getAccess installation on the same system. Another option is a distributed installation in which back-end getAccess applications are installed on the LDAP server and front-end getAccess applications are installed on a separate server. Given getAccess' poor performance results, distributing the components across multiple servers is most likely the better option to improve the numbers.
Of the products we tested, getAccess was undoubtedly the easiest to implement. Although Entrust does not offer a Java client, its Web-based administration interface was quite easy to use. We quickly added a Web server resource, secured several areas of our Web site and assigned permissions to our users and groups.
The Web-based getAccess interface is strong, but not as good as the Java interfaces offered by SecureControl and SelectAccess. GetAccess' management interface comprises a user/resource-management system and a service-control system. These two interfaces allow for delegation of daily maintenance, involving users and permissions, and systemwide configuration maintenance, for authentication-provider management. DirectorySmart uses a similar division of management services. GetAccess offers no unique features, but its administrative capabilities and integration impressed us. Adding services with the system-configuration wizards is a step-by-step snap.
GetAccess' interprocesses are secured with SSL for internal services and communication with LDAP servers. In our tests, we began our session with an SSO request to a protected resource on our Web site. The system directed our request to a login page, which passed the credentials to a back-end AARS (authentication and authorization routing service). The AARS determines the authentication request (in our case, LDAP) and processes the login. Once we were authenticated, AARS retrieved our access privileges and established our user session with the session-management service. All user-profile information -- such as the user name, role and IP address -- was encrypted in a session cookie and sent back to the browser.
Because getAccess kept our credentials in a cookie during our session, the Web server never needed to reauthenticate or test for access permissions. In addition, once the Web server starts up, the getAccess module contacts the getAccess back-end services and requests a complete list of protected URLs and the associated roles. This authorization information is stored in memory on the Web server. In this way, getAccess limits the number of requests to the back-end services each time a user accesses a protected resource. The trade-off for this kind of performance is the possibility of data getting stale. However, getAccess, like most of the products we tested, offers an option to purge the cache and push the updated information to the Web servers immediately.
REPORTS
ANALYTICS
Follow 
