User:Rageller/Sandbox

What is Web Access Management? Web Access Management is a subcategory of the broader Identity Management (link) space. Web Access Management controls access to Web resources, providing: •	Authentication (link) Management •	Policy-based Authorization (link) •	Audit & Reporting Services (optional) •	Single Sign On (link) Convenience Authentication Management is the process of determining a user’s (or application’s) identity. This is normally done by prompting for a username and a password. Additional methods of authentication can also include tokens (link) (which generate one-time passwords) and digital certificates (link). Once a user’s (or process’) identity is confirmed, Policy-based Authorization comes into play. A Web resource (such as www.foo.com/admin) can have one or more policies attached to it that say “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 lookup 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 (which is more of a benefit to IT and administrative staff), and offer Single Sign On. Single Sign On is the process by which a user logs in only once to a Web resource, and then is automatically logged into all additional related and protected resources. Users can be inconvenienced when attempting to get authenticated to multiple websites throughout the course of a day (potentially each with different usernames and passwords). A Web Access Management product can record the initial authentication, and provide the user with a cookie (link) that acts as a temporary token for authentication to all other protected resources, thereby only forcing the user to log in once.

History Web Access Management products originated in the late 1990s, and were then known as Single Sign On. Two of the original players were Computer Associates Siteminder and Oblix Access Manager. 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 users 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. Since then, Single Sign On has come to mean the technology that lets end-users store all their passwords in a browser plug-in which auto-fills login screens for them (such as RoboForm). The new term became known as Web Access Management, because products in this space added the functionality of controlling which resources (Web pages) a user could access, in addition to authenticating them. Architectures There are two different types of architectures when it comes to Web Access Management architectures: plug-in (or Web agent) and proxy. Plug-ins are programs that are installed on every Web/application server (link), register themselves with those servers, and are called at every request for a Web page. They intercept the Web request in order to make a policy decision and communicate with an external policy server in order to make these decisions. One of the benefits of a plug-in-(or agent-) 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 plug-in is required for every Web server on every platform (and potentially every version of every server). 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 (link) to the back-end Web/application servers. One of the benefits of a proxy-based architecture is a more universal integration with Web servers since the common standard protocol, HTTP, is used instead of vendor-specific APIs (link). One of the drawbacks is that additional hardware is usually required to run the proxy servers. Solutions like CA Siteminder typify the agent-based approach; maXecurity from P2 Security employs a proxy approach. Costs It is often underestimated how much a Web Access Management system truly costs. In most cases, the annual maintenance costs dwarf the purchase price. For example, when policy servers are used (in both the plug-in and proxy-based architectures), high-end hardware is needed in order to efficiently run the WAM infrastructure. Users will give up on accessing a Web page if it takes more than several seconds to respond http://en.wikipedia.org/wiki/World_Wide_Web#Speed_issues. 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 WAM is similar in concept to a firewall (link) (more closely aligned to an application-layer firewall), it must be able to handle major audit requirements, especially for public companies subject to SarBox (link)(not to mention those that are bound by HIPAA, PCI, or CPNI). Larger companies spend tremendous amounts of time and money auditing these WAM infrastructures since they are the enforcement points for so many of internal and external applications. Proxy-based architectures have been shown to significantly reduce the initial and recurring costs of WAM. External References