Applied Oracle Security: Developing Secure Database and Middleware Environments- P39 ppt

This page intentionally left blank PART III Identity Management This page intentionally left blank CHAPTER 8 Architecting Identity Management 357 358 Part III: Identity Management his chapter discusses the architectural processes and methods used for solving the identity management problems that many enterprises face today when trying to secure access to their applications and information. “Architecting” a solution requires that you understand the functional nature of the problem (such as protecting customer data from privacy threats, and so on) and create a technical solution to address those problems. Often, as technical people, we can get caught up with possible technological solutions before we fully understand the possible ways of solving the problem from a practical perspective. Subsequently, this chapter covers common techniques and patterns that help you quickly and easily understand the full nature of the challenge surrounding unauthorized access to information applications and a methodical approach to applying appropriate technology solutions to meet those challenges. Keep in mind that this chapter does not intend to cover the comprehensive Oracle Identity Management product portfolio and instead intends to lay out some key products from those offerings in the context of building key identity management solutions. Understanding the Problem with Identity Management Recall from Chapter 1 that security can be simply described as understanding who gets access to what, from where, when, and how. In this chapter, we will focus on the first two aspects: Who are you? What can you access? In the most fundamental and simplistic view, identity management means managing information for the “who can access what” answer. You may not realize it, but we are all accustomed to dealing with identity management in almost every aspect of our lives. A classic example for which both the notion of identity and access is used to fulfill a transaction is when you walk into a bank and withdraw money from your checking accounts through an in-person teller. The teller usually requests a proof of identity (such as a driver’s license or passport). Once the identity information has been verified—or authenticated, as we like to say in the security world—the teller looks at your account details to see what funds you have access to withdraw. If both the identity and access requests are verified and asserted, the transaction is successful. Essentially, every information transaction scenario follows the model of this bank teller transaction. Before any functional request can be filled, some prerequisite verification of that activity using identity and access information must occur. Although it’s a well-understood and practiced exercise in many parts of our day-to-day business and personal lives, implementing security inside our IT systems can be more challenging. Real-world IT differs from the physical world analogies because of the numerous security models employed and various ways in which applications and programs can represent the users (or the who’s) as well as how they authenticate the users, authorize the users, and control access for the users. Many people consider identity management to be nothing more than a by-product of a generation of application development that was too focused on short-term requirements. After all, it is not a revolutionary concept to authenticate, authorize, and audit user activity inside applications and databases. However, does it make sense to have this infrastructure embedded ■ ■ T Chapter 8: Architecting Identity Management 359 inside every application? The policies to authenticate, authorize, and audit might vary from application to application, but it does make sense to have them all use a common foundation for making those decisions, and that is precisely the problem identity management solves. Let’s return for a minute to the bank teller example. One of the differences between the bank teller and our electronic information access scenario is the level of trust achieved during a typical transaction. For instance, the bank teller is physically present with the individual making the request, whereas in an electronic scenario, the individual could be literally anywhere in the world. The bank teller is physically receiving the identity document and as such has better assurance that the document was not modified or tampered during the handoff process, whereas in the electronic information access scenario, identity information is presented over a network and therefore is susceptible to tampering during the transmission process. Such differences in the style of a physical bank transaction and the electronic transaction contribute to a basic difference in trust between the server and the client. While this notion of trust is an easy concept to comprehend, it is the hardest to implement in any nonphysical and electronic use case because of three keys limitations in a typical application that does not leverage a centralized identity management architecture: central issuance authority, identity verification, and identity propagation. Central Issuance Authority The bank teller has the luxury of being presented with a trusted identity document such as a driver’s license or a passport. In the case of a driver’s license, the state or a country takes responsibility for issuing such identity documents, which essentially removes the problem of trust between a typical customer and the bank, since both parties implicitly trust that the issuing authority has performed the appropriate identity vetting and issued a document that cannot be easily falsified. Unfortunately, not all information enterprises can claim such a trusted central authority for issuing identity assertions. The last generation of application development focused on short-term deliverables and local authentication routines with local usernames and passwords at the cost of having a centralized and universally accessible set of identity credentials. The closest we have come to a central issuing authority is Active Directory in enterprises that use it for Windows networking purposes. However, application architects are often reluctant to trust the Active Directory infrastructure to provide a secure set of credentials since it typically does not have the strongest change management processes and therefore could pose a significant risk to the enterprise if credentials are compromised. Identity Verification In the bank example, when the customer handed the teller a driver’s license or a national passport, the teller can perform some basic verification tasks to validate that identity document by verifying personally identifiable information (such as Social Security numbers, signatures, PIN numbers, and so on). If the transaction requires more sensitivity, the teller can also ask for additional nonstandard identifiers and verifications, such as mother’s maiden name or the dollar amount of some recent transactions. These kinds of verifications and cross-verifications allow the teller to build the required level of trust incrementally to help with the customer. When this scenario is replayed in an electronic format, an information application is typically able to handle the direct and standard verification of the user, most likely using a password; however, few applications natively provide the ability to perform nonstandard cross-verifications. Such advanced authentication needs are usually implemented with a lot of custom coding and added complexity that becomes quite difficult to maintain. 360 Part III: Identity Management Identity Propagation The entire bank transaction usually occurs physically in front of the teller, who is most likely sitting inside the bank premises and, therefore, in a somewhat secured context. As a result, when the customer is providing proof of identity, this happens directly from the client to the teller (the server in networking parlance)—in other words, direct identity propagation occurs. This characteristic is challenging to achieve in information applications with intermediate layers (middleware) between the end user application and the backend database. For instance, a typical three-tiered deployment could have end user applications (such as JavaServer Pages [JSP] pages and ASP.NET) communicating with middleware components (such as JavaBeans and Web Services) communicating with other middleware components or data tiers (such as relational databases and file systems). This kind of multi-layered architecture risks losing identity propagation for reasons including the lack of integration standards and identity formats. I have witnessed many web application deployments in which the end user identity is passed on from an HTML web tier to a Java 2 Platform, Enterprise Edition (J2EE) middle tier but not propagated onto the SQL database that serves as the data tier. The J2EE would simply connect into the database using a shared account that accessed the database for all end users. This is a classic example of how the failure of identity propagation from the middleware to the database can result in low assurance that the right data is being given to the right end user, since the database cannot control access based on the end user’s identity. Identity management exists not because it mimics a bank transaction. It exists because when it is employed it not only adds a central identity authority, identity verification, and identity propagation, but the right identity management solution introduces a platform for security administrators to improve the quality of the security enforcement continuously by improving the policies (such as parameters used to access and control the information). Better policies usually lead to a higher degree of trust, and a higher degree of trust leads to higher adoption of this infrastructure across applications. And a higher degree of adoption usually leads to an overall lowering of the cost of security, since you are able to reuse infrastructure and share efficient enforcement practices across multiple applications. If you compare the cost of implementing the identity management infrastructure, you would see that cost is far less than the cost of building it redundantly everywhere. Architecting Identity Management Until recently, identity and access management were not very widely-used terms in a security context. For the most part, identity management was associated with Lightweight Directory Access Protocol (LDAP) directories, such as Novell’s eDirectory, and was seen as the means to manage user credentials for operating systems and networks (such as Windows Networking using Active Directory). While that is a perfectly legitimate view of identity management, it should not be limited to those specific contexts. The same basic challenges of user authentication, authorization, and auditing exist in every IT architectural component that involves end user interaction, such as web portals, customer management systems, point-of-sale systems, analysis and reporting tools, online storefronts, content management systems, and so on. As a result, architecturally, we need to realize that we can realize a lot of benefits if we apply the simple LDAP architecture used for basic OS-level authentications to every other user-facing application in the enterprise. As a result, a slightly broader view of identity management can be defined as Chapter 8: Architecting Identity Management 361 follows: Identity management is a solution that decouples user management from enforcement of access policies inside applications. The core challenge of identity management is balancing centralization of management with the decentralization and localization of enforcement. To arrive at the point where we are true to the definition, we need to assess the enterprise’s maturity level with respect to security infrastructure. Centralization of identity management requires some basic “IT plumbing” to be in place or be developed before we can truly centralize user management and automate access provisioning. The existence of these key prerequisites of centralization and automation will drive our architectural and implementation choices, since we must often focus first on setting up the basic plumbing, such as integration and storage facilities, before we architect the identity management infrastructure. As a result, we usually start the architecture process at what architects often refer to as the “discovery” phase, when we ask questions to assess and qualify the problem’s current state and scope. Identity Management Discovery Experience has proven that proper time and attention early in a project reaps tremendous benefits later. Setting up an identity management system certainly follows this tenet. Spending extra time to understand the as-is application security models and their purpose will generally result in a much more effective solution. A simple test to determine whether you are ready to start architecting a security solution for any security problem is to ask yourself the following questions: Do I understand the organizational model of the enterprise dealing with the identity management problem? How is authority distributed? How are the applications and business processes accessed to perform daily business? Do I understand the data that needs protection? Who needs it and how much? As the questions demonstrate, three areas of discovery must be addressed when trying to solve a typical identity management problem: people, process, and data. People discovery should focus on identifying the players around a specific application or information repository. These players can be groups, organizations, and roles associated to a specific information access problem. Process discovery should focus on identifying the relationships among people (users, groups, organizations, roles, and so on) and the applications by identifying the steps by the different types of users to carry out a business process inside the application. It should reveal the access privileges required for different users inside each application that is relevant to the business process. Data discovery is similar to process discovery, except it focuses on the relationship between people and the information being accessed. It should identify data ownership, data privacy, and the data storage system. The outputs from this area should form an access privilege model that includes users inside each database (that is, which roles should map to which privileges). The following sections provide samples questions in each of the three areas and more ideas on how to use the information gathered when answering those questions. Discovering Identity Management Requirements Around People At a fundamental level, an identity management problem demands a better and more efficient way to manage information regarding people and their relationships to resources. So it is useful to start by understanding the types of people (users, groups of users, and so on) that are part of the equation. ■ ■ ■ 362 Part III: Identity Management The approach is a simple one: Try to capture the Identity Management Organizational Model (IMOM). The IMOM is similar to the organizational model that exists in a typical HR system, except IMOM can span from internal employee populations to external user populations, such as customers and partners. The following is a basic list of information elements that are useful to capture when trying to uncover the people-centric data for an identity management problem: Organizations The logical units that form the entire organization (for example, Oracle North America, Oracle India, Corporate Marketing, Product Development, and so on). Functional roles An inventory of business roles that are relevant to the application or information (such as Sales, Marketing, Product Development) Authority levels The categorization of authority and seniority of people in the organization (such as Level 1 Analyst, Senior Manager, Director, Vice President, and so on) User types The types of users accessing the protected applications and information (for example, Employees, Customers, Contractors, and so on) Identity attributes Additional identity information used to classify access to information, such as employment status (Full-time, Intern, and so on), physical location, security clearances, and more. NOTE The IMOM tries to consolidate all relevant users to the problem including internal users (such as employees and contractors) and external users (such as customers, partners, suppliers, and so on). Discovering the internal user information is usually not too difficult since the HR system is likely to possess most of that information. However, data about external users can be difficult to ascertain and requires additional effort to collect and verify. The IMOM information can serve as direct inputs to your exercises in defining corresponding objects in the Oracle Identity Manager (OIM) component of your solution, as you will learn in Chapter 9. For instance, if the organization is relatively fluid (that is, reorganized frequently), you might consider keeping the organizations flat and simple in OIM and relying on people’s roles and responsibilities to encapsulate their organizational associations. So, for example, if there are frequent reorganizations of who reports to whom in the sales organization, you could use a single “Sales” organizational design in the identity management system with a set of roles or groups (see Chapter 9 for exact definitions of these concepts) to represent either further organization classification (such as geography and product segments) or functional responsibilities (such as Sales Representative, Territory Manager, and Presales Engineer). External users can be difficult to model since those types of users don’t always follow neat organizational hierarchies as internal employees do. So, for example, it is not always obvious how to handle external partners that need to access certain applications. Unfortunately, there are no absolute right answers to many of these organizational design questions, but keeping the litmus test of flexibility is always a good idea. Consider changes in the partner’s identity, role, authority, or relationship to the enterprise and see how well your design manages those changes. You don’t need to spend a significant amount of time understanding the organization model because, most likely, you will want to iterate through your design several times before committing to the implementation. Keep this discovery step to a minimum and leverage this information in the next steps of discovery. ■ ■ ■ ■ ■ Chapter 8: Architecting Identity Management 363 Discovering Identity Management Requirements Around Process Another view of an identity management problem is viewing application security in the context of a business process that executes web services across multiple applications to complete a business function. For instance, a bank customer opening a new online bank account can initiate a business process that subsequently invokes corresponding web services in multiple relevant applications (such as the customer relationship management system, marketing promotions system, and check card management system). Parts of this business process might include direct human interaction (the customer opening the account) and part of this process might be automated (adding a new record into the marketing promotions system). From a security point of view, you need to understand the sensitivity of the different steps in the process and the information that flows through each step. You are not really solving the security problem if all you do is authorize and authenticate the customer to the online banking application and avoid security in the subsequent automated steps. Even if the subsequent steps do not involve direct human interaction, the web services offered by the applications are just as vulnerable to attacks as a user-facing application would be if it didn’t have any security checks. The desired model for web service security should be a seamless and transparent authentication/authorization check before a user or web service client executes the step. To get to that desired model for security for a given business process, you should ask some high-yielding questions: What are the end-to-end steps of the business process? What is the human interaction workflow in the business process? In other words, explain who (that is, which business roles) can execute which step of the process? What information is flowing between each step? What part of that information is sensitive and should be available for display? Can a web service be accessed without providing a human user identity? Is security being enforced across the business process using the same human identity information? If not, where is the actual end-user’s identity propagation ending, and whose identity, if any, is being used in the subsequent process steps? Ideally, these questions, if answered properly, should illustrate the business process and steps with the highest vulnerability for attacks on your information from unauthorized access. The last two questions usually reveal whether a centralized identity management strategy is in use across multiple applications, especially in enterprise application integration scenarios. In addition to understanding the security for processes and workflows, you also need to understand processes for security, especially identity management. To uncover the nature of the business processes dealing with identity management, you need to ask some of the following questions: What are the steps in the process for provisioning a new identity (for example, employees, customers, contractors, and so on)? What are the approval workflows? What are the steps in the process for provisioning a transfer or job change? What are the steps in the process for deprovisioning an existing user? What are the compliance-mandated attestation processes for information access? This is an artifact of the Sarbanes-Oxley Act of 2002 (refer to Chapter 9 for more information). ■ ■ ■ ■ ■ ■ ■ ■ ■ . pages and ASP.NET) communicating with middleware components (such as JavaBeans and Web Services) communicating with other middleware components or data tiers (such as relational databases and. typically able to handle the direct and standard verification of the user, most likely using a password; however, few applications natively provide the ability to perform nonstandard cross-verifications understand the possible ways of solving the problem from a practical perspective. Subsequently, this chapter covers common techniques and patterns that help you quickly and easily understand the