How can security policies be centralized across an enterprise's set of Web applications? In particular, we examine the case of security policies for web services and for traditional websites and describe how the two can be administered and enforced together to improve both the cost of administration as well as the strength and flexibility of the security system.
Web Services and Websites: Different or the Same?
In contrast Web Services, a more recent innovation, involves the use of XML technology to link systems together. Many standards such as SOAP and WSDL enable web services to work across highly heterogeneous and distributed systems. Web services operate on an application-to-application basis rather than human-to-computer as in the case of a traditional website. The communications from the client to the service uses XML as the common language. This allows one application to call the services of another application over the network by sending an XML message to it.
Just as is the case with websites, web services require security policies that govern their usage and behavior. Security product categories such as the XML Gateway and broader identity-centric web services security systems have emerged in order to apply security policy to web services in a centralized way. To date, generally these web service security policies have been enforced independent of WAM-based policies used for website control, even when both types of web applications are deployed in the same organization.
Given the relative immaturity of web services deployments, it has been reasonable to operate with web services security policies and website security policies in isolation from one another. Web services security systems can deal with protecting application-to-application traffic, while separate website security products can deal with actual human beings accessing websites using browsers. However, changes in the maturity of the technology and the organizations that are using it are driving a more holistic approach to enterprise web security. This allows organizations to eliminate security silos even before they have been created.
Securing web services has a lot in common with security for websites, in that threats need to be mitigated, requesters need to be authenticated, access needs to be authorized, and sessions need to be maintained. This is why there is an emerging trend toward combining the services of XML Gateways with systems very much modeled on web access management systems; what we will refer to as identity-centric web security systems or shorthand as a Web security system.
When an XML Gateway or a specialized web service agent is used in combination with the centralized policy server of a web security system, it enables security policies to be configured and managed centrally, but enforced in a highly distributed fashion. In this approach the XML Gateway/web service agent/policy server operates in the same best practice PEP/PDP (Policy Enforcement Point/ Policy Decision Point) architecture that security administrators are so familiar with from their Web Access Management (WAM) products.
In Figure 1, we see an XML Gateway being used in the DMZ to manage XML traffic coming in from the Internet. In addition, agents are being used at a Portal Server and at back-end Web services to enforce security policy within those containers. Security policies are being centrally managed with a centralized policy server. In this model the XML Gateway and the various agents fulfill the role of a PEP using policies from the centralized policy server that acts as the PDP. However, from the point of view of the XML traffic, this is only part of what the XML Gateway can do. As well as acting as a PEP, the XML Gateway also:
A Centralized Policy Server is a central store of security policies that govern the usage of web and web service resources. These policies secure not only HTTP-related traffic but other forms such as SOAP, JMS and MQ using the familiar PEP/PDP security architecture.
In Figure 2, we see both website (browser to website) and web services (application to application with XML/SOAP) traffic being secured with the same web security system. Users who access the web server may indirectly access the web services also, if they are using a web application that makes use of the back-end web services. Notice that when the Policy Server is used for both Web Access Management and XML Security, it effectively becomes a Centralized Policy Server, controlling access for an enterprise's entire set of web sites and web services.
The Agent at the web services container provides last mile security by enforcing security policies on traffic that arrives directly at the web service.
Tying the User to the Service
In this case identity information is passed to the back-end web service by means of a session token. In this way, the policy enforcement points can make a decision based on the identity of the person authenticated at the website, even though that person is "one step away" from the back-end web service. It can use the Policy Server to determine if the user has a valid session and also to look up attributes of the user that are used for authorization or personalization. In this way the user does not have to be authenticated twice, once at the website and once at the back-end web service. Instead, the WAM session token is used for single sign-on to the back-end web service.
The steps in this typical scenario are shown in Figure 3.
Enter Web 2.0
Web services are the technology used on the server side to power Web 2.0 sites. As the user navigates the web page, code is executing in the browser, which connects back to web services at the host site to fetch more information for the user, usually using technologies such as REST and the XMLHttpRequest (XHR) object. This all happens without the user being required to navigate to a new page. For example, Google Maps uses code running in the browser to connect back to web services to fetch more map "panes," even when the user is not dragging the map, so that when they do drag the map, the extra map area is "magically" present. MySpace allows users to change their profile right within a browser page, without the requirement to submit a web form or wait for a new page to load. This also uses code in the browser that connects to web services to perform its actions.
Enterprise users now familiar with consumer sites such as MySpace and Google Maps are demanding more interactive functionality than what has been provided by the static sites of the past. This increased functionality, while beneficial for users needing better access to data and services, represents a real and growing security challenge for enterprises. Users of online banking systems, web-based ordering and tracking systems, and sales force automation systems now expect Web 2.0 functionality. For example, it is attractive to allow online banking users to query and sort their transactions directly in the browser, pulling the data in real-time from web services at the server side, without the requirement to reload the page each time. The use of these web services to fetch such sensitive information rightly starts to ring alarm bells for the enterprise's security professionals.
Let's look at a specific example of a Web 2.0 site that is also driving Website security and web services security together. In Figure 4, access to the website is controlled by a cookie-based WAM product. Users of the website, once authenticated by the WAM product, use a Web 2.0 application in their browser. The Web 2.0 application makes use of web services to fetch dynamic content (for example, to fetch an insurance quote in real-time). We see an XML Gateway with an identity-based web services security system being deployed to manage access to the web services. By connecting the XML Gateway to the policy server of the web services security system, a single security system can be used to govern access to the website and the back-end web services. In addition, the XML Gateway protects the enterprise from harmful XML. The XML Gateway, acting as the PEP, enforces access to the web services and ensures that only authenticated users are allowed.
Security administrators who are skilled with using a WAM product for controlling access to websites can now use it in its extended capacity to define policy for accessing the web services used to power Web 2.0 features. In this way, retraining is not required and greater leverage of existing infrastructure and security processes can be leveraged. When the centralized policy-based system is used for both Web Access Management and web services security, it effectively becomes a Centralized Web Security System covering both flavors of web application deployment.
Putting It All Together
This can be achieved by using an XML Gateway and container-based agents in conjunction with a centralized identity-centric web security system. The full solution architecture is shown in Figure 5.
In Figure 5, we see all three scenarios that we have examined in this article. Working from the top to the bottom, we see:
In this model the centralized web security system makes access decisions that apply to all web resources, whether browser-based or web service-based. The XML Gateway acts as an enforcement point and applies XML threat mitigation and XML traffic management (caching, routing, XML enrichment), paired with the agent-based enforcement points that extend the security coverage to the last-mile, to the service. In this way security administrators only have to manage one set of security policies and one set of infrastructure across both websites and web services for the entire enterprise. This sets up the security administrators for eased security management and better control, in effect eliminating security silos before they have even been built.
About Matthew Gardiner
About Mark O'Neill
Get HelpContact Us
Follow Us on: