After an authentication or authorization policy decision is made, the outcome can be recorded for auditing purposes, such as: 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, the process by which a user logs in only once to a web resource, and then is automatically logged into all related resources.
One of the benefits of a plugin (or agent) based architecture is that they can be highly customized for unique needs of a particular web server.
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 (APIs).
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.
For example, when policy servers are used (in both the plugin and proxy-based architectures), 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.
Since web access management is similar in concept to a firewall (more closely aligned to an application-layer firewall), it must be able to handle major audit requirements, especially for public companies subject to the Sarbanes-Oxley Act (not to mention those that are bound by the Health Insurance Portability and Accountability Act, PCI, or CPNI).
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.