Web access management is a form of identity management that controls access to web resources, providing authentication management, policy-based authorizations, audit and reporting services and single sign-on convenience. Authentication management is the process of determining a user’s identity. This is normally done by prompting for a user name and a password. Additional methods of authentication can also include access tokens and digital certificates. Once a user's identity is confirmed, policy-based authorization comes into play. A web resource can have one or more policies attached to it that say e.g. "only allow internal employees to access this resource" and/or "only allow members of the Admin Group to access this resource." The requested resource is used to look up the policy, and then the policy is evaluated against the user’s identity. If the user passes the policy evaluation, she/he is granted access to the resource. If the user fails the evaluation, access is denied. After an authentication or authorization policy decision is made, the outcome can be recorded for auditing purposes, such as:
determining the last login time of a user
identifying attempts to gain access to protected resources
logging any administrative actions
As a benefit to the end user, a web access management product can then tie this security together, and offer single sign on, the process by which a user logs in only once to a web resource, and then is automatically logged into all related resources. Users can be inconvenienced when attempting to get authenticated to multiple websites throughout the course of a day. A web access management product can record the initial authentication, and provide the user with a cookie that acts as a temporary token for authentication to all other protected resources, thereby requiring the user to log in only once.
History
Web access management products originated in the late 1990s, and were then known as single sign on. Five of the original products were Hewlett-PackardHP IceWall SSO, CA Technologies SiteMinder, Oblix Access Manager, Magnaquest Technologies Limited IAM and Novell iChain. These products were simple in their functional capabilities, but solved an important issue of the time – how to share user credentials across multiple domains without forcing the user to log in more than once. The challenge stemmed from the fact that cookies are domain-specific, so there was no simple way to seamlessly transfer a user from one website to another. The new term became known as web access management, because products added the functionality of controlling which resources a user could access, in addition to authenticating them.
Architectures
There are three different types of architectures when it comes to web access management architectures: plug-in, proxy and tokenization. Plugins are programs that are installed on every web/application server, register with those servers, and are called at every request for a web page. They intercept the request and communicate with an external policy server to make policy decisions. One of the benefits of a plugin based architecture is that they can be highly customized for unique needs of a particular web server. One of the drawbacks is that a different plugin is required for every web server on every platform. Further, as technology evolves, upgrades to agents must be distributed and compatible with evolving host software. Proxy-based architectures differ in that all web requests are routed through the proxy server to the back-end web/application servers. This can provide a more universal integration with web servers since the common standard protocol, HTTP, is used instead of vendor-specific application programming interfaces. One of the drawbacks is that additional hardware is usually required to run the proxy servers. Tokenization differs in that a user receives a token which can be used to directly access the back-end web/application servers. In this architecture the authentication occurs through the web access management tool but all data flows around it. This removes the network bottlenecks caused by proxy-based architectures. One of the drawbacks is that the back-end web/application server must be able to accept the token or otherwise the web access management tool must be designed to use common standard protocols. Solutions like CA SiteMinder offer both agent and proxy based options while including standards based federation. maXecurity from P2 Security employs a proxy approach. NetIQ Access Manager offers a hybrid solution that consists of both proxy and J2EE agent approaches. TELEGRID SMRTe employs a tokenization approach.
Costs
In most cases, the annual maintenance costs dwarf the purchase price. For example, when policy servers are used, high-end hardware is needed in order to handle the workload required to run the web access management infrastructure. Centralized administration is an additional hidden cost, because customers will need to hire and train staff to exclusively manage policy entitlements for the underlying web applications. A final hidden cost relates to regulatory compliance. Since web access management is similar in concept to a firewall, it must be able to handle major audit requirements, especially for public companies subject to the Sarbanes-Oxley Act. Larger companies spend tremendous amounts of time and money auditing these web access management infrastructures since they are the enforcement points for many internal and external applications.
