| Even though the dot.com era is now considered history, its legacy, the Internet revolution, still remains and influences organizations to Web-enable their current and future portfolio of business solutions, regardless of complexity, at a dot.com pace. There is no question that today's applications must reach the desktops of their target audience through a Web browser ”the current application delivery medium of choice. However, to serve a network of enthusiastic Web-based application users efficiently and effectively, organizations have had to culturally and technically shift away from their traditional approaches to software development, for example: -
Adopt agile software development methodologies specifically geared toward rapidly capturing business requirements and the incremental development and testing of software components . -
Build multilayered (presentation, business, and integration) component-based application architectures using Web-oriented technologies, such as J2EE, and reliable application infrastructures , such as WebLogic Platform. -
Design and implement an end-to-end security infrastructure that encompasses every aspect of their Web-enabled business solutions. -
Find mechanisms to allow interoperability between business solutions and the aggregation of data/information from multiple repositories. -
Investigate techniques to seamlessly embrace emerging Web technology standards for business logic processing and communication, such as Web services. In an ideal organization, all the preceding efforts would be practiced in a structured and coherent manner across all business landscapes (units). This practice allows business solutions to evolve from inception to implementation, using consistent and interoperable application and security infrastructures ”hence the investments in future-proofing the technology infrastructure. In reality, organizations have been quite successful in Web-enabling their business solutions. However, the adoption of consistent and interoperable application and security infrastructures between business units has not been successful, which is the underlying reason that organizations today face the following technical challenges: -
The complexity and costs related to Enterprise Application Integration ( EAI ) efforts have overshadowed the actual software development efforts and costs. Note EAI is the process of creating an integrated infrastructure that tightly couples disparate systems and data sources across an organization to provide a bi-directional solution so that data between important internal systems can be shared and exchanged.
-
A comprehensive, flexible, and unified security infrastructure cannot be established, which has the following effects: -
Potentially prevents Web applications based on different technologies from leveraging and expanding on existing investments in the security infrastructure. -
Hinders interoperability and integration (trust) between secure Web applications that have diverse application security models. -
Prevents business units from protecting their security infrastructure investments, as their security policies become recast in synch with changing organizational business processes and policies. Even though EAI can often be an afterthought in a software development effort, and is nearly always a costly process to implement because it is never an out-of-the-box solution, organizations are slowly meeting the EAI challenges through the following methods : -
The custom development or purchase of application adapters and gateways, such as those application vendors develop using J2EE Connector Architecture (J2CA). -
An enterprise messaging system, also known as Message-Oriented Middleware (MOM), which supports messaging for applications that span different operating systems and machine architectures. For example, the WebLogic Messaging Bridge, which is part of the WebLogic Server subsystem, enables you to pass messages between the following components: -
Any two implementations of WebLogic Java Messaging Service (JMS), including those from separate releases of WebLogic Server -
WebLogic JMS implementations that reside in separate WebLogic domains -
WebLogic JMS with a third-party JMS product, such as IBM's MQSeries -
WebLogic JMS with a non-JMS third-party messaging product (although you need to obtain a custom adapter from the third-party vendor) -
Web services, which provide a distributed computing technology for revealing an application's business services on the Internet or an intranet using standard XML protocols/formats and open Internet standards, such as Web Services Description Language (WSDL, to describe), Universal Description, Discovery, and Integration (UDDI, to advertise and syndicate), Simple Object Access Protocol (SOAP, to communicate), and Web Services Flow Language (WSFL, to define workflows). Note The use of standard XML protocols allows Web services to be platform, language, and vendor independent, and ideal candidates for use in EAI solutions.
However, implementing security for a Web application can never be an afterthought, as in the case of EAI. Every Web application requires some level of security, with the top- tier objectives including: -
Everyone is denied access unless specifically allowed access. This requires an authentication scheme, a process by which an entity, such as WebLogic Server, verifies the identity presented through a request, such as by an end user. This process usually requires some form of credential information being passed, such as a password known only to the end user . -
The application's security model must enforce business policies concerning which authenticated requests have access to which application resources. This process is known as authorization . -
Auditing who is accessing the Web application and how application resources are being utilized. -
The data flow between the client and the Web application must be understood and categorized, with data that's considered intellectual assets or confidential protected through an encryption mechanism while in transit. Because every organization is unique in its internal behavior, the reasons behind organizations having arrays of non-interoperable security infrastructures can be endless, as shown in the following examples: -
A federated approach is used to develop Web applications, which sometimes carries the weight of a non-unified and legacy perception of how security objectives are implemented. These legacy security perceptions include the following: -
All Web applications are unique and, therefore, have unique security objectives that require their own security infrastructures. -
Security mechanisms can be home-grown, and integrating with a commercial security vendor is considered too expensive, too complex, and overkill. -
A Web application's security objectives should be derived from its implementation technology capabilities. -
Developers should be accountable for implementing security objectives and policies for a Web application. -
Security objectives and policies should be managed, enhanced, and evolved only in the context of a Web application. -
Purchased vendor-driven Web applications come bundled with proprietary security mechanisms. -
Ghost technical and political decision logic is used that only a select few understand ”this type of logic is referred to as organizational paranormal activity . As the demand for sophisticated Web applications increases in organizations ”for example, portal solutions that consolidate functionality and content and demand personalization services based on the end user's identity ”organizations must seek to manage all aspects of a user's online identity in a coherent manner across the enterprise. This concept, known as identity management , embraces the principles of single sign-on, in which an end user is authenticated only once to access an enterprise Web application, instead of requiring a login to each individual enterprise system for which access is required. To reach this security nirvana, organizations must approach Web application security from a systemic point of view. This implies that all areas of an organization's security requirements and infrastructure must be considered together. The following sections outline two basic best practices that organizations have successfully used to standardize, evolve, and simplify an identity management system for their Web applications. The Formation of Social Infrastructures to Support a Security Ecosystem All organizations must be aware of the types of IT infrastructures used to support their business solutions. Using techniques such as cataloging organizational infrastructure patterns and developing technology taxonomies , organizations can quickly develop an inventory list of existing IT infrastructures and forecast the types of technologies required to implement future business solutions. Your organization's technical agility is greatly influenced by how it uses this information to leverage existing technology investments and justify the acquisition of new IT infrastructures. The most practical and efficient way to manage and evolve a security infrastructure from a systemic perspective is to bring together technology and business advocates from different aspects of an organization who have a passion for enterprise security ”the Security Group. The Security Group should be formally recognized in the organization with a charter to standardize, evolve, and simplify over time how a security infrastructure is adopted and used. Tasks related to this charter should include the following: -
Quantify the enterprise risk and associated costs of the following factors: -
The temporary or permanent loss of data -
The theft of data or identity -
The disruption of application availability -
The cost of preventing illegal data and identity use -
The loss of productivity and revenue from the disruption of application availability caused by a breach in security -
Develop and refine a corporate security policy. Because no security policy is generically applicable to all enterprises , each enterprise must determine the appropriate amount of risk for the information it disseminates. In practice, it is the business unit's responsibility to leverage and, at a minimum, be compliant with the corporate security policy. Note A security policy is a specific, concise document that explains the following: -
The rules by which people given access to a organizational business information system must abide -
The exact measures that will be taken to protect systems data -
The specific responsibilities of people using those systems -
How the policy can evolve
-
Review and advocate industry security standards for existing and emerging technologies. -
Review the capabilities of security infrastructure products against the organization's security needs. Based on knowledge gathered from risk assessment and supporting security policies' requirements for a Web application, the Security Group should work with business units to promote a flexible and interoperable security infrastructure standard for the organization's applications (for example, firewalls, network intrusion detection system, antivirus systems, authentication and authorization systems). The proposed infrastructure should accomplish the following: -
Be flexible enough to encompass the needs of all current mission-critical Web application technology platforms, while striving to take advantage of new security technologies as they emerge. -
Reduce the cost and administrative burden of managing and authenticating user identities that can span multiple business units. Note The authentication model that an enterprise chooses defines the infrastructure that all applications will follow. The choice of an authentication model is important because most businesses have difficulty migrating from an accepted model later.
The Functional Abstraction of Security from Application Code Before the Internet revolution, many applications were developed with the presentation and business logic tightly coupled together, as is the case in the client/server paradigm. This approach caused problems for organizations that wanted to take advantage of implementing Web interfaces for their applications. For this reason, many organizations had to painfully re-create their applications to separate business logic from presentation logic. Having learned their lessons, organizations today take advantage of J2EE and the concept of abstracting presentation logic from business logic to develop their Web applications. However, only a few organizations have been able to take this concept forward to build abstractions in other areas, such as security. For Web applications to leverage a common security infrastructure, a level of abstraction for security must be created. This approach avoids the following: -
Application developers having to write security-aware code. -
Modifying application code to be aligned with new security policies. -
Redeploying and certifying an application after security code has been changed. -
Administrators being aware of J2EE infrastructure and other supporting technologies related to application deployment, such as XML. The bottom line is that organizations that have not begun to abstract security code from their application code will have to re-architect their applications to implement the same kind of abstractions for security so that they can leverage the next new wave of security infrastructures. The following sections introduce the completely redesigned security service-oriented architecture of BEA WebLogic Server 7, which provides a comprehensive, flexible security infrastructure designed to address the security challenges of Web applications. The WebLogic Server security services can be used standalone to secure WebLogic Server applications or with any best-in-breed third-party security management solutions that your organization has standardized on. |
