Container level approach

To share information with a wide variety of users and to facilitate valuable partner and customer interactions, organizations are creating increasingly collaborative environments with shared touch points, using IBM WebSphere Portal, Microsoft SharePoint, and custom applications built in Java and Microsoft .NET

development environments. These shared touch points have brought about an enhanced user experience that needs to be controlled based on business needs without compromising any company specific information.

As organizations are building these portals and applications, they like to externalize the security policies that influence the behavior of the application or portal. Typically, these policies are based on business needs of the organization and can often change when business drivers or processes change. One way to help facilitate this situation is for applications and portals to externalize security enforcement to the application server container and focus only on the business logic. The container can then be integrated with a security policy management solution so that it can enforce the security policies defined by the business and influence the behavior of the applications and portals.

This approach to externalize application security from the application server container and have the container influence the behavior of the application by using a security policy management solution is called the

container level

approach

. This architecture pattern is typically used when developing new applications or portals or for application re-engineering. Examples of application containers that can be integrated with a security policy management solution include J2EE container, SharePoint, ASP.NET, and so on.

Let us review the need for a container based approach through the following financial services example.

2.2.1 Customer example

A large financial institution is offering some of their services through online portals. This action proved successful, so more and more customers take advantage of these online channels. The institution now wants to add more services to its portals, including the most critical ones that expose a variety of mission-critical applications and services. These services involve the exchange of critical data such as credit card numbers, social security numbers, and other personally identifiable information (PII). Now the organization faces the

challenge of ensuring in a productive way that user access remains secure. They must also secure access to critical data from inside the organization. Corporate security policies dictate that this access be managed on a need-to-know basis to minimize risk of both intentional and unintentional data loss or breach of data security.

Hardcoding security controls into these applications can generate redundant logic, while running the risk of introducing inconsistency among applications. Once in place, such controls are difficult to change, and they contribute to increased operational costs and security risks for the organization.

Here are some of the specific challenges that this organization and the financial services industry in general are facing:

򐂰 Being among the earliest IT pioneers, they have a long history of core applications that were written for an entirely different environment. Portals and service veneers are used to provide interfaces that serve today’s needs. 򐂰 New business initiatives and rapid growth have caused the establishment of a

variety of application platforms using different technologies that are inconsistent in many ways.

򐂰 A number of mergers and acquisitions has added even more to the

inconsistencies in IT. As a result, governance requirements and the need for better cost efficiency mandate a consolidation. Conversely, a smooth migration path is needed to not disrupt the daily business.

򐂰 The trend towards one-stop financial services has forced cooperation among formerly separate types of operations within the organization, such as banks, insurance companies, and building associations.

򐂰 The financial services industry worldwide is governed by a number of government regulations and standards. Compliance is not an option; it is mandatory.

򐂰 The observed overwhelming trend towards online banking and other self-service offerings available to customers has raised the bar for security controls. Sensitive financial data combined with PII is sent across the public Internet and demands the best possible protection. Incidents of fraud can damage reputation overnight.

From the above challenges these needs emerge: Applications should not have to code their own security mechanisms, a centralized approach is required for security policy management, it has to cover both external and internal

communication, and a set of common security services are needed that can be used across all platforms and that can be easily adapted to change.

Given the fact that the core business of our financial services organization depends 100% on the availability of its underlying IT systems, high availability and resilience are paramount. This situation has two immediate consequences for security services, including the security policy management:

򐂰 The security services themselves must have failover mechanisms in place. 򐂰 Special attention must be paid to the prevention of denial-of-service attacks

against the security services.

2.2.2 Integrating policy at the container level

We now take a look at the steps required to establish the container level security policy enforcement approach. The most common implementations of this approach involve portals and application servers, most of them either based on Java or .NET. A security policy management solution should therefore support at least these two.

Interfacing with the container

There is not a single common interface available for security policy management across all application container implementations. A policy management solution must therefore provide a flexible, extendable, and modular architecture to be able to support the consolidation challenges that we have described for this pattern. It should support existing standards for obtaining external policy decisions, such as

Java Authentication Contract for Containers (JACC)

, a well-established industry standard within the J2EE environment, by

implementing a JACC provider. Standard solutions for widely deployed platforms such as SharePoint are desirable. An API to enable custom-made interfaces on other container platforms will serve as a last resort if nothing else is available.

Discovering application resources

The possibilities for automatic (or easy) discovery of application resources depend heavily on the available interfaces a specific platform provides. For example, SharePoint provides a web service that can be used to discover SharePoint resources. J2EE platforms have the potential to enable easy discovery of resources such as ESBs, web URL patterns such as JSPs, and roles through use of administrative interfaces. Unlike the web services environment with its service description language, there is no universal description language for a container in general. A good approach can be to normalize to an intermediate descriptive format similar to what exists for web services, which can help facilitate the resource import from different sources.

Policy administration

All aspects of policy administration depend on what the container platform can offer and what is standardized. In the case of J2EE, there is existing standards work that can be used. For example, a J2EE profile for the generic XACML policy description language provides mapping of J2EE resources. This is a good starting point for policy authoring, whereas role mapping needs to integrate with the respective container runtime environment and its integration with user authentication mechanisms. A consistent support for security policy

administration across multiple J2EE based container platforms appears to be both desirable and achievable. A good security policy management solution should provide capabilities to support other containers, such as SharePoint policy administration, and be open to further extensions.

Policy enforcement at the container

This is the core aspect of this pattern. The fact that the applications are unaware of the security policy decisions helps to keep them simpler and easier to

maintain. Developers can focus on the business logic and do not need to become security experts. Business agility is increased as changes and new applications are implemented quicker. Consistency of security policies across distributed environments more easily achieved and verified, both for existing and new applications. In the case of portals, the portlets take the position of the applications, so policy enforcement is externalized from them as well.

Auditing

In a highly regulated industry, auditing is one of the most important aspects of security policy management. Being able to place this function at the container level makes it easy to build a consistent, all-encompassing auditing and reporting solution that includes both the policy management itself and the business transactions, provided there is standard auditing support within the deployed IT security policy management solution. A need for additional log and event management capabilities may still arise due to compliance requirements and government regulations.

More information about the container level approach can be found in Chapter 6, “Container level integration” on page 159.

In document IT Security Policy Management Usage Patterns Using IBM Tivoli Security Policy Manager (Page 65-69)