364 Part III: Identity Management These questions should generally cover almost any identity management–related processes in a typical enterprise. Answering these questions should give you a comprehensive view of how identity management is conducted in the current environment and, therefore, should help you prioritize the processes that have the highest complexity and highest risk of authorized access provisioning. For example, automating the deprovisioning process may not drive the highest cost savings but may reduce the risk of having a disgruntled employee with access to mission-critical systems. Understanding and prioritizing these goals will help you identify which problems to solve first. Discovering Identity Management Requirements Around Information Every action and investment made in the name of identity management is done for one reason: enforcing that the right person is accessing the right resource (that is, information). Information is an amorphous concept since it exists in so many shapes and forms across the enterprise in so many systems and so many databases. The challenge around information security discovery is knowing what information looks like in each system and knowing who should access what parts of the information. It is important that you keep a functional/business view and definition of data. For instance, they should be classified by how a business analyst would look at the data (for example, customer data, product data, employee data, supplier data, finance data, facilities data, and so on). Classification should not be driven by their technical characteristics (such as XML, Oracle e-Business Suite 11i, SAP, Business Intelligence, and Austin Data Center). Policies around accessing information should also follow a similar approach and remain as technically neutral as possible, at least at this phase of the project. An example policy around access controlling the finance data could be that a finance analyst can query and read the current quarter earnings data but cannot update or delete that data. Nothing in that policy statement seems to refer to the technical characteristics of the data and, instead, suggests to us that “latest quarterly earnings data” can be read by someone with the finance analyst role but cannot be updated or deleted, regardless of where and how it exists. To simplify and accelerate the requirements-gathering process around information, you can use the following framework: 1. Inventory all critical systems and applications according to their enterprise name. 2. If those systems are not classified as functional systems (such as HR, Finance, CRM) and instead classified as technical systems (such as Oracle Applications, SAP, Project Nexus Business Intelligence), you need to take some additional time to classify the data that exists in each of those technically-classified systems to reveal what they hold. Often a single system can hold many types of data, usually in a data hub scenario where various data is often combined to provide marketing business intelligence capabilities. The output of this step is to produce a matrix like the one shown in Figure 8-1. 3. Compile a list of functional business roles that exist across the enterprise. This step can be started in parallel with the first step. 4. Map each of those roles to the types of data. 5. For a box that has an X in the mapping (shown in Figure 8-1), map the business roles to local application or system-specific roles that already exists or can be created in that particular application or system. Chapter 8: Architecting Identity Management 365 Through the use of this basic framework, you will reveal the mappings from business roles, to data types, to applications containing that data, to the local application roles that guard the lowest layer of the information architecture. For instance, you could have the following as an example set of mappings: Marketing Analyst —> Product Data —> Project Nexus —> Viewer This example illustrates how a functional role (such as Marketing Analyst) can be mapped to a technical Viewer role in the Project Nexus system. The discovery of these mappings will serve as essential input to help you create the access policies around the Marketing Analyst role to the Product information that lives in the Nexus system. In addition to discovering the rules around access policies for information and applications, you also need to discover and understand the privacy and compliance policies that exist for that information. For example, if financial data exists in a system, it might require that you implement certain auditing policies that track exactly who accessed what record and performed what kind of changes to those records (such as read, write, update, deletes, and so on). In addition to access controlling the data records, additional compliance requirements may exist around the application security model, such as separating the roles of the system administrators of the applications or databases (such as the DBA) and the logical owners of the financial data (such as financial analysts and executives). These kinds of requirements are very common in an enterprise that needs to comply with laws such as Sarbanes-Oxley, Section 404. So, to deal with such compliance or mandate requirements, you could add to your previous framework another set of mappings between the type of data and the compliance requirements and other mandates concerning the information or applications, as shown in Figure 8-2. FIGURE 8-1 Role-to-data mapping 366 Part III: Identity Management Even though these mini-frameworks are somewhat obvious and simple, they can be useful to an identity management discovery practitioner. They focus on breaking down complex legislative and other compliance mandates to simple requirements that can be mapped to the necessary identity management and security solutions. This is also true of any useful framework in this space. Many people cringe when they hear the word “framework” in any security project. However, over time, creating a framework has become a proven way to gain a better understanding of how solutions are developed and maintained over the long term. Identity Management Patterns After you have done a reasonable amount of discovery around the identity management requirements and the enterprise as-is state, you should be at a point at which you can start the “exploration” process for what the solution should look like, given the inputs from the phase discovery and the general experience of an architect in solving these kinds of problems. To accelerate the process of finding the right solution, you may find it useful to refer to a set of architectural patterns that represent possible solutions for a type of problem (for example, user provisioning, web access control, and so on). The words “reference architectures” and “best practices” are often tossed around with these patterns. However, you should try to refrain from making any value judgments regarding these patterns, since one person’s best practice can be another’s worst. While reference architectures are useful to “reference,” it’s not very useful to follow them without understanding the consequences of their implementations. In this chapter, you will read about an approach of placing certain context with every architecture pattern and considering which circumstances are appropriate for keeping them around or replacing them with new ones. These patterns can also serve to provide the architect with a solution baseline that can be tailored to meet specific requirements. Applying Patterns by Enterprise Maturity One of the first tasks after the discovery exercise is to use the information gathered about enterprise security architecture to determine the maturity of the organization with regard to security and identity management. An identity management problem is always better solved when you know the limits of the current capabilities, since you can project how well, or if at all, the desired business objectives are going to be met with those existing capabilities and technology FIGURE 8-2 Compliance and mandates discovery Chapter 8: Architecting Identity Management 367 investments. If the current capabilities are unable to meet the desired business and enterprise objectives, you can identify the gaps, in terms of the capabilities that need to be developed, and therefore focus your architecture efforts to address those areas. One tool for illustrating those gaps at a high level is a maturity model framework, shown in Figure 8-3. The job of this maturity model is to categorize any security architecture into a known maturity level, which demonstrates where a particular architecture is in its evolution spectrum. In each of the boxes shown in the figure, the heading represents the maturity level (tactical, coordinated, or strategic) followed by the main focus of the implementation work (Integration, Automation, or Optimization). The following describes each of the maturity levels and what could lead you to categorize any identity management architecture into any one of those boxes. Tactical These are relatively simple solutions that focus on key technical pains for the security administrators in the organization. The focus of these solutions is the act of integrating security information and actions across multiple systems and applications. If you are a security architect or engineer facing challenges around integrating identity information among multiple systems or integrating authentication session across applications (for example, a web portal authentication scenario) or dealing with setting up role-based access control of your databases using LDAP servers, you are more of less at a tactical maturity level for your security architecture. Keep in mind that working through these types of pains that come at this level is a prerequisite to solving the problems posed in subsequent maturity levels. Once again, the simple litmus test for categorizing as tactical is in the answer of whether the architects are mainly solving data and system integration problems. FIGURE 8-3 Identity management maturity model framework 368 Part III: Identity Management Coordinated This is the next evolutionary step after dealing with tactical security challenges such as identity information integration. In this maturity level, architects try to deliver higher value solutions to the enterprise by automating the processes around identity management. Business processes, such as employee on-boarding, and IT processes, such as password resets, are often convoluted and expensive manual processes that can be automated through the use of identity management technologies. This is the maturity level that most enterprises have been targeting for the past couple of years, and, therefore, the technologies and offerings have focused on these kinds of challenges as well. An enterprise should be categorized in the Coordinated maturity level if the architects are focused on process automation challenges around identities and access. Strategic This is the final and most evolved category for any security architecture. At this level, the challenges no longer involve tactical integration or identity management automation. Those hurdles have been overcome, so, at this level, enterprises can focus on creating and optimizing governance policies/processes across all systems, applications, and organizations to align security with the operations of the enterprise. Enterprises that have arrived at the strategic maturity level typically have security embedded within their application development process so that any new capability or application service development is required to pass a phase where the applications are secured using standard enterprise-wide governance and compliance guidelines and policies. Using Different Maturity Models This maturity model is just one approach to breaking down maturity levels. Many similar maturity models are available from many sources, but the model presented here demonstrates how it can be used to navigate successfully through a set of tactical solutions before attempting to solve strategic and enterprise-wide identity management issues. It is a good idea to start with a relatively narrow problem scope since you will inevitably learn key lessons during your tactical implementations that should affect your more strategic initiatives around identity management. NOTE The maturity model doesn’t necessarily apply only at the enterprise level; it can apply to individual applications as well. For instance, different applications can be at different maturity levels within the same organization, perhaps due to different resources and priorities for security. So you may need to apply the maturity model individually to different applications to apply the appropriate solutions to each application. Maturity levels can correlate to the kinds of architecture patterns in use. As Figure 8-4 illustrates, the architecture patterns also evolve as an enterprise moves through the maturity levels. The early days of identity management focused mainly on point-to-point directory synchronizations and replications, which then evolved to a hub-and-spoke architecture for centralized user administration, and now this space is also heading and orienting itself around the notion of identity and security services. Each of these architecture styles is valid and appropriate with respect to the enterprise’s current maturity with its security software infrastructure. It is not a good idea to force an environment to adopt a solution architecture too advanced for the existing infrastructure; this can result in failed implementations. A lot of learning occurs during the process of moving through the different architectural models, such as point-to-point and hub- Chapter 8: Architecting Identity Management 369 and-spoke patterns. At every phase of the architecture’s maturity, you can observe the strengths and weaknesses of each architecture pattern and use them through the maturity process. For instance, an enterprise should not aim to build out a service-oriented security platform before solving some basic problems such as centralized user provisioning and directory management. As a rule of thumb, you should try to design an architecture that fits current capabilities rather than trying leapfrog to an advanced maturity level. An organic progression through maturity levels is less risky since it lets you identify the enterprise’s strengths and weaknesses around identity management and therefore, tailor your solution to avoid possible pitfalls. Now that you have a sense of architectural maturity, let’s explore each architectural pattern that is typically involved in each of those maturity levels. Point-to-Point Pattern A point-to-point architecture is used to solve tactical needs of integration, such as keeping passwords in sync or managing roles and privileges across multiple directories. Basically, it is a solution for synchronizing identity information between application silos. An example of a point-to-point implementation is a directory replication. All major LDAP servers (Oracle, Active Directory, SunOne, and so on) have the notion of replication built into their core products, and we can spread out many instances of each directory over large geographies and still maintain a certain level of consistency of identity information. Alternatively, you can have point-to-point integrations for synchronizing between heterogeneous applications and environments such as the Oracle and the Microsoft technology stacks. However, the fundamental solution is the same: synchronize user identity from one repository to another without necessarily changing how that user information is managed and administered in each of those systems. The advantage of a point-to-point architecture is that it is a relatively simple solution to understand and implement. It also does not change the control of the information in any system, since the administrators of the different systems are still as powerful and as free to do as they wish with their data. However, the point-to-point model has significant limitations when the enterprise is looking to centralize management to a single point of control. Also, it adds complexity in terms of managing independent point-to-point integrations of identity and access information between applications. Therefore, if this style of integration starts to grow in an enterprise, the architecture should start to consider the next phase in its evolution, hub-and-spoke. FIGURE 8-4 Maturing though the patterns of architecture 370 Part III: Identity Management Hub-and-Spoke Pattern The hub-and-spoke pattern looks similar to a standard Ethernet switch in today’s computer networking landscape. A single device supports many connections using a standard networking interface to allow for all connected parties to communicate. Similarly, an identity management infrastructure, if properly configured, can act as that central hub for managing users and their access into all your enterprise-wide systems and applications. Once every application and system is connected into this hub, users are able to communicate with each other through this standardized and centralized identity management infrastructure. Keep in mind that not all connected applications carry the same weight and influence. Some of the applications connected to this identity management hub may be more influential and may drive the identity management processes in the other applications. For instance, the data from the human resources application (for example, PeopleSoft HCM or SAP HR) can drive the user provisioning policies and processes to the other connected applications (such as ERP systems and LDAP servers). Identity management hub-and-spoke architecture requires a bit more design and planning than a pure point-to-point implementation, since you need to establish some enterprise-wide ground rules for identity. For instance, if all identities are going to be centralized into a single hub, an enterprise user naming convention must be implemented. While you can continue to use application-centric usernames, the enterprise naming conventions need to map to those local application usernames. The benefit of this approach is centralization and therefore reduction of the cost and complexity of managing new and existing identities in the enterprise. It can provide some simple but powerful centralized solutions, such as password resets and new account services across all systems. This approach is critical for an enterprise looking for an audit compliance and governance solution. A centralized identity management hub can provide a single view and report on who has access to what systems. It can also provide workflow services so that all those accounts are regularly inspected and attested for continuing authorization, as mandated by laws such as Sarbanes-Oxley. Another key benefit of the hub-and-spoke model is that it allows for a much simpler integration model into heterogeneous packaged applications (for example, Oracle Applications, SAP, Windows Server products, and so on) if you are employing a solution such as Oracle Identity Manager (OIM) that ships with a library of standard prebuilt connectors. (Refer to Chapter 9 for more details on OIM’s integration capabilities.) While a majority of customers and enterprises today are spending most of their investments in ramping up to this hub-and-spoke architectural pattern for identity management, it does have certain limitations. The limitations are especially pronounced when we try to integrate custom- developed applications or services that are being developed inside the enterprise. While it is possible for a custom application to integrate into the centralized hub to leverage existing identity management services (for example, new user provisioning, runtime authorization decisions, runtime auditing, and so on), this is usually a development and maintenance nightmare. Due to the lack of standards around the identity services, it is almost always a one-off integration that cannot be reused and extended over time. The benefit of a centralized Identity management service infrastructure is quickly drowned out by the pains of writing that custom integration code and maintaining it over the lifespan of the application. Such integration limitations in the hub-and- spoke model has given birth to a new generation of architecting security called service-oriented security (SOS), also referred to as security-as-a-service. Chapter 8: Architecting Identity Management 371 Service-Oriented Security Pattern To address the cost and complexity of making changes to existing applications or building security for new applications, many leading-edge enterprises are shifting to the next evolution, SOS. The following is the official Oracle definition of SOS (www.oracle.com/us/corporate/press/015428_EN): Service-Oriented Security decouples hard-coded security features from enterprise applications to create reusable, standards-based security services and protocols which any application can consume. SOS enables organizations to simplify and centralize several critical security processes including authentication, authorization, user administration, role management, identity virtualization and governance, and entitlement management, as well as audit and control. SOS is a not necessarily an architecture by itself, but a pattern of architectures that advocate the use of standardized services using industry-defined interfaces that provide a complete set of identity management and security capabilities for both home-grown and off-the-shelf applications. SOS relies on standards around Identity management, such as Extensible Access Control Markup Language (XACML), Lightweight Directory Access Protocol (LDAP), and Service Provisioning Markup Language (SPML), which are standardized interfaces for basic security functions such as authorizations, identity data access and provisioning. Another key benefit of SOS-based applications is that they can leverage standards such as XACML to provide much stronger access control with much deeper integrations with the information application. Application developers are able to leverage and reuse standard security services such as authentication, authorization, user provisioning, role management, identity federation, and auditing. This can be done much more efficiently and without the necessity of knowing the specific implementation details of the security services. The developer of a new application, in a non-SOS environment, will need to write complex and often hard-coded policies dealing with authorization of data inside their applications. With SOS, instead of writing all those policies inside the application, the developer can refer to an externalized service that abstracts and encapsulates all the details of the security policies that are created and maintained by people who better understand that domain (for example the line of business that application will serve). This model is much more efficient since it breaks up the new application development effort and allows people to focus on their core competencies. Also, it is very beneficial in terms of managing changes to security policies or the application itself, since either type of change can occur much more seamlessly. Under a SOS pattern, you can define standard business access policies that can be reused across any application that needs to enforce those decisions. For instance, you can centrally define an “Exec Management Access” policy in your authorization server that allows access to anyone with a “Vice President” title and above to access certain reports in your financial application. However, if tomorrow you need to lock everyone except the CFO out of that policy, you could make that simple policy change underneath the “Exec Management Access” policy by removing all roles except CFO. This approach does not require any changes to the applications enforcing that decision, since applications rely on the SOS-based authorization service to make the decision. SOS brings a new way of managing and enforcing identity management policies to the enterprise. However, you should not try to jump to this new style for the sake of being on the cutting-edge. Instead, the progression to SOS should be a natural requirements-driven process that adapts existing infrastructure to working in that new model. SOS, by definition, is a way to reuse 372 Part III: Identity Management existing investments in infrastructure and policies, so ripping and replacing current working components to adopt SOS will fundamentally miss the point of SOS. Oracle Identity Management Solutions So far in this chapter, we have discussed identity management architecture from the point of view of problem discovery, environment assessment, and possible architectural patterns. In this section, we will start mapping those problems to solutions available by using Oracle products. Figure 8-5 represents the typical identity management solutions that you will need to solve the problems discussed so far. User Provisioning A user provisioning solution allows you to manage a user’s account and access privileges across many enterprise applications from a centralized management engine. The Oracle solution for user provisioning is built using a centralized hub-and-spoke architecture. You can create and manage identities in a single logical place and via an integration solution, corresponding accounts can be created in the appropriate applications that enforce access. The key component in the Oracle solution is the Oracle Identity Manager (OIM), Java-based product with a centralized identity hub and an integration framework that connects that hub to all the applications and systems in which user accounts are to be created. Figure 8-6 illustrates the architecture for an Oracle Identity Manager in a typical enterprise-wide deployment. As you can see, OIM is typically a centralized hub used for managing and provisioning those identities to all the enterprise systems. However, OIM is not necessarily the “source of truth” and can be driven by an authoritative source, such as an HR application, to provide key events and information about the identity. Once OIM receives such a trigger event, it can then execute provisioning processes to create accounts and privileges in downstream applications based on the access policies predefined in OIM. Just as it can trigger new account creations, it can also trigger changes and revocations of existing accounts if the original event signaled this. You can turn OIM into a central governor of accounts across all applications in the enterprise so that simple business events can have cascading effects on those accounts as appropriate. This style of centralized provisioning can eliminate all the redundant work that would otherwise occur in each individual application. FIGURE 8-5 Identity management solutions Chapter 8: Architecting Identity Management 373 NOTE Chapter 9 provides much more detail about developing user provisioning solutions using Oracle Identity Manager Directory Management A directory management solution offers the enterprise a central, scalable, and efficient user repository, mainly for applications and clients needing to access identity-related data. This solution is one of the basic pillars on which identity management solutions rely for quick and reliable access to identity-related data. The following are the key capabilities of a directory management solution: An LDAP-based directory service offering a fast access to identity information A reliable and scalable storage of organized identity data A directory integration mechanism that presents data from multiple backend sources Oracle Directory Management offers all these capabilities, but it packages them according to two styles of directory integration capabilities: meta-directory versus virtualization. NOTE Directory virtualization refers to an approach in which identity and access information is integrated at runtime from multiple backend sources and presented as a single record. Virtualization follows a composite service design pattern for identity data. Oracle offers synchronization (also described as a “meta-directory”) functionality within Oracle Internet Directory product to synchronize between OID and other third-party directories so that the information is constantly kept synchronized between multiple LDAP servers. Oracle ■ ■ ■ FIGURE 8-6 OIM user provisioning . shapes and forms across the enterprise in so many systems and so many databases. The challenge around information security discovery is knowing what information looks like in each system and knowing. discovering the rules around access policies for information and applications, you also need to discover and understand the privacy and compliance policies that exist for that information. For. such compliance or mandate requirements, you could add to your previous framework another set of mappings between the type of data and the compliance requirements and other mandates concerning