In recent years, changing business requirements have necessitated the need to open up internal applications to customers, partners, employees, and contractors with a varying degree of access to each. This has significantly changed the paradigms for application development, brought in a great deal of changes to the way an enterprise is secured, and the security aspects of an enterprise are managed. This article delves into the changing security needs of enterprises and the emerging patterns in delivering and managing security.
Introduction
The internet revolution has made it possible for businesses to open up and reach out – not just to a huge number of customers but also to suppliers, partners, employees, remote teams etc. A business’ capability to interact electronically with all these entities is both crucial to its growth and important for its survival as it is even directly related to revenues. However, with that come the challenges – how do you open up your systems to various degrees for several parties to access only the resources they need? How do you implement security in your software in a safe, manageable, scalable and maintainable manner?
Good Ol’ Times: Build a Wall
This is a time-tested, and by no means an obsolete, approach towards security – build a wall, make sure it is high enough to make your world invisible to invaders and strong enough to withstand enemy’s assaults. The network security infrastructure with a set of firewalls and other hardware/software mechanisms was acceptable in good old times when the focus was on securing your enterprise resources from outsiders. However, in the context of modern businesses, it is more than protecting the resources; it is also about sharing them with the right entities (employees, customers and business partners – both people and applications). A business needs to be less restrictive in allowing access to its internal resources while maintaining tight grip on who accesses what and firewalls are not a satisfactory answer to that. Businesses also have to deal with issues around insider attacks – it is unsafe to assume that anyone within the firewall is trustworthy and can be allowed access to all resources.
Insecure from Inside: Spaghetti Locks
To extend the security to inside the network boundaries by taking the application-centric security approach extends security to within the network boundaries by putting the access control closer to the resource. The application serving the information must authenticate and authorise the user to ensure that the right person is accessing the right information. However, for that to happen, responsibility of security shifts to application developers who:
· need to know about the resources and the organisation’s security requirements around those resources,
· must understand the security requirements of upstream and downstream modules in the application, and
· implement security constraints embedded in the code along with the business logic.
The description of requirements and approach to developing such a system itself spells out the issues with this approach. Such systems not only burden the developers with expanding their core competency to understand security aspects, they also reduce the productivity and make the application development highly error prone. Most application code will eventually become spaghetti of security and business logic, making it virtually impossible to debug/maintain.
A Brave New World: Application Security Infrastructure
The solution to problems above is to build an application security infrastructure (ASI) that maintains an application-centric security approach but pushes security enforcement to infrastructure level, thereby:
· letting the developer focus on business logic,
· reducing security holes by reusing well-tested security infrastructure,
· separating business logic from security policy, allowing both to evolve independently and making applications more maintainable, and
· lowering the total cost of ownership.
This approach has matured significantly over the last several years and has become the foundation stone for large enterprise application architectures. One shining example is the security model in Java 2 Enterprise Edition or J2EE. In fact, let us take J2EE as an example and explore the salient features you should expect from an application security infrastructure.
J2EE has relieved the developers of coding security logic and made it into a system service. The idea is to let system specialists handle security enforcements while the developers focus on writing business logic. J2EE delivers all the aforementioned benefits of ASI. We will go through those with J2EE as an example.
· Security experts (application server providers), and not business developers, write security software.
· Application developers are more productive doing just what they are best at – writing JSP/Servlet/EJB and other business logic.
· With a clear separation of business and security layers, the applications are highly maintainable – if the business logic modifies, you just change your application. If a security upgrade is needed, you just upgrade or patch your application server.
In general, application security infrastructures would allow a programmatic interface to power developers and a declarative mechanism for us. The J2EE infrastructure provides both – one can specify the security requirements declaratively in deployment descriptors, independent of the application code or use the security API to hardcode security logic in the application. The declarative approach is available for both Web tier (Servlet/JSP access) and Component tier (Enterprise JavaBeans). At the Web tier, one can control access to any particular web resource or a group of them by defining a url-pattern and mapping it to certain roles in a special deployment descriptor (web.xml).
Here is an example of a security constraint as defined for a J2EE application in its web.xml.
<security-constraint>
<display-name>Leave Management – Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>leaveAppWeb</web-resource-name>
<description>Admin Area</description>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>Admin User</description>
<role-name>leaveAppAdmin</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Without getting into the details of each element above, here is what the above descriptor informs the J2EE application security infrastructure.
· All resources matching the URL pattern /admin/* are restricted resources.
· Only users in role leaveAppAdmin should be allowed access to any resources matching this URL pattern.
· The transport-guarantee of CONFIDENTIAL requires that the infrastructure transmits data in a fashion that prevents other entities from observing contents of the transmission. In most cases, that implies the application requires use of SSL.
As you can see, the developer can totally forget about securing access to the web application while developing the application. These constraints can be specified after developing the application and can modify anytime, independent of how the application logic itself evolves. The declarative security example above can be extended to EJB tier also where one can declarative define, even at method level, the roles that can access a certain resource. The syntax is slightly different but the advantages are similar, and it conveys the same message – application security infrastructure using declarative security management is a powerful, developer-friendly approach towards developing maintainable, secure applications efficiently.
Generation Nxt: Service-oriented Application Security Infrastructure (SOASI)
A service-oriented architecture (SOA) is essentially an application architecture where all functions are exposed as services with well-defined interfaces. Such architecture decouples implementation (logic and even choice of technology) from the service’s interface and provides a collection of reusable, maintainable and integration-friendly services that can be orchestrated in a well-defined manner to form business processes.
With the web services as an underlying technology for delivering SOA, it is gaining tremendous amount of support in the industry and seems to be the next evolutionary step in helping enterprises meet their IT challenges starting from developer productivity, time-to-market, extensible and maintainable systems and, most importantly, integration.
Taking the concept of SOA to even infrastructure services, a service-oriented application security infrastructure exposes a set of reusable, location transparent, distributed enterprise security services that handle security requests across the enterprise while maintaining a centralised policy management and administration. Let us first run through the salient aspects of SOASI as defined above:
· Reusable: These services only expose a granular interface to the application, making it easier to reuse the security services and build higher-granularity services by orchestrating them.
· Location Transparent: The service should be truly transparent to the application for it to be a real, distributed service.
· Distributed Security Service: A distributed architecture reduces the cost of integration and allows the services to be reused across the enterprise in heterogeneous environments.
· Centralised Administration: For ease of administration, it is vital that all security services use a centralised repository for policies and present a unified management interface.
However, there has to be mechanism to push these policies close to the resource, at enforcement points, for a truly distributed security configuration.
Fig. 1: The service-oriented application security infrastructure (SOASI) approach
This kind of approach allows each aspect of enterprise security to be implemented and made available to the rest of the enterprise as a set of independent, reusable, distributed services. The architecture should also support plugging-in new services or extending them for dynamic future needs of the enterprise.
For example, BEA Weblogic Enterprise Security (WLES) is one such product on the market that has employed and enabled the service-oriented approach to enterprise security. It provides several security services like authentication, authorisation, auditing, identity assertion, dynamic role mapping, etc. out-of-box, and provides an extensive API for rapid and simplified development of new security services.
You must have noticed when discussing the J2EE security model that security is applied more like an implicit service, which the J2EE platform provides to all its applications under-the-covers if the deployment descriptors are properly configured. Even the programmatic security is made available to applications through API that is hidden under different kinds of Context objects. Service-oriented security Infrastructure is an extension of this concept with a service-oriented focus. One can still incorporate security declaratively in applications, just that the underlying platform orchestrates security enforcement as a service and makes it available as a service for programmatic security management.
Conclusion
Security needs of enterprises have changed drastically over the past several years, so has the approach to security. Starting from the times of simple network security infrastructure and spaghetti of business and security codes, we have refined and improved the security approach to using wholesome application security infrastructures like J2EE security model. The service-oriented approach to application security infrastructure takes the concept a step further to serve the next generation business requirements of:
· Reusable, location transparent and extensible distributed services
· Separating business and security logic for higher productivity, easier maintainability and specialised development focus
· Implementing consistent, synchronised security policies across the heterogeneous enterprise, and
· Interoperable and standards-based security infrastructure to protect investment in third-party security technologies.
Anil Sharma is an expert on J2EE technologies and has been working on developing middleware infrastructure software while working at BEA, Oracle, and Pramati.
|
