Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

By now it should be clear that trusted security infrastructures may change the face of IT security in the years to come. Obviously, the road ahead will be long and challenging.

One of the key TSI problems remains mature and interoperable security standards. Although lately a lot of new standardization efforts have been bootstrapped (efforts like XKMS, SAML, and so forth), all of them still have to gain widespread acceptance in the TSI marketplace. Another challenging question is how Web services will impact TSIs.

1.5.1 Overview

Figure 1.5 summarizes the current TSI product offerings. From this figure it becomes apparent that currently no universal TSI solution is available that spans all dimensions. This includes authentication, authorization, and security administration services, and also the different TSI client access methods: office/enterprise, Web-based, wireless-based, or remote access– based. Figure 1.5 also shows the important step forward made by EAMS products. The latter will be explained in more detail in Section 1.5.2.

From the architecture diagrams in this section, you should remember the commonalities between the different TSI services. For example, all of them deal with repositories and interact with an enterprise management system in one way or another. This underlines the importance of a global TSI approach: Too many large enterprises use an island approach when dealing with TSI. They may have a provisioning, PKI, and EAMS project, but they miss the glue that makes these projects come together. Communication, coordination, and standardization are key, certainly in this critical IT space.

1.5.2 Unified TSI example: EAMS

Extranet access management systems (EAMS) are a good example of TSI solutions where different security services are bundled in one commercial software offering. EAMS can be defined as a unified solution for Web authentication, SSO, authorization, and security administration. Because EAMS were born in the Web portal world, they are focusing on HTTPbased access to Web resources.

In the first place, EAMS are TSIs providing centralized authorization decision making and enforcement. EAMS decouple authorization decision making and/or enforcement from applications and services and centralize these services at TTPs. EAMS also include centralized security management (covering identities, credentials, and roles), can provide authentication services, and provide a set of accounting services.

Figure 1.5: TSI overview.

In the future EAMS may be extended to cover other access methods as well. For example, a couple of EAMS vendors already provide RADIUS support for remote access. Ideally, EAMS should also be extensible to cover more than just Web-based applications. Some EAMS vendors have included this functionality in their product. However, in the latter case, the role of the EAMS is limited to centralized authorization decision making.

Over the last two years, EAMS have been a major success story in the security world that has been supported by many software vendors. With the creation of EAMS, vendors were responding to customer demands for more powerful extranet security features. Customers were asking for group-based and role-based authorization support, self-registration for users, SSO across multiple Web sites, and a centralized administration model that also allows managers to delegate administrative tasks.

EAMS are made up of a central policy engine containing the EAMS logic for authorization, authentication, auditing, and security administration services. Note that for authentication and security administration services, EAMS may call on some external authentication or security management TSI. The EAMS policy engine may also provide the intelligence for EAMS functions such as self-service administration, delegation administration, password synchronization, and so forth. Authorization security policies can be managed by the EAMS itself or, depending on the degree of centralization, using tools that come with the security management infrastructure. The EAMS infrastructure interacts with a repository (database or directory) to store and retrieve credentials, user identity information, attributes, and authorization data. EAMS servers are obviously linked to an auditing system and may have management agents from the corporate IT infrastructure management software installed. Finally, the security services provided by the EAMS infrastructure will be used by a set of applications.

The EAMS software products available on the market today can be grouped in two categories:

• In an agent-based EAMS, clients always communicate directly with the application servers. The latter have an EAMS agent installed that validates every client request with an EAMS policy server. The EAMS policy server makes the access control decision and sends the response back to the application server. The application server’s EAMS agent then allows or denies client access accordingly.

• In a proxy-based EAMS, clients never communicate directly with the application servers. Situated between the two, an EAMS proxy intercepts every client request and enforces access control. The EAMS proxy communicates with an EAMS policy server. The latter is the access control decision maker—the proxy functions as an access control traffic filter.

Table 1.5 gives an overview of EAMS products out of the two categories available on the market today.