374 Part III: Identity Management FIGURE 8-7 Oracle Directory Management offers the virtualization within Oracle Virtual Directory (OVD). OVD offers any LDAP clients the ability to query a single LDAP proxy to query many physical LDAP and non-LDAP identity repositories. The technique of directory virtualization is being rapidly adopted over synchronization and meta-directory techniques, since it does not require information to be physically synchronized between servers and so results in a cheaper and faster approach to identity data integration. Oracle Directory Management architecture is shown in Figure 8-7. NOTE Chapter 9 discusses the Oracle Directory Management story in more detail and shows how you can apply OID and OVD together and independently to solve the basic challenges of creating a central logical location for accessing identity information related to any user in your enterprise. Authentication Management Authentication management is a category of solutions for identifying and verifying a user’s identity. The tactics for the identification process can vary widely, but they always focus on proving that a user is who he or she claims to be. Authentication management does not try to solve the issue of verifying authorizations, which is a separate category altogether. The following types of solutions are included in this category: Single sign-on (SSO) The ability to reuse an authenticated session in more than one application. Enterprise single sign-on (ESSO) The ability to integrate an operating system-level authentication or a thick desktop client’s authentication with that of your web SSO. ■ ■ Chapter 8: Architecting Identity Management 375 Strong authentication and fraud prevention The ability to provide stronger levels of authentication and risk analytics to prevent identity fraud. Federation The ability to integrate web authentication across partnered enterprises. Database authentication Centralizes the authentications for database repositories to a central user repository (for example, LDAP). The Oracle Access Management suite offers all these solution both as independent solutions and as an integrated bundle. Figure 8-8 shows the products that support each of these solutions. Authentication management solutions are part of any access management architecture in which a specific need exists to integrate authentication between one or more applications or technology platforms. For each of these solutions, a server component manages and evaluates the authentication policies and an enforcement agent component is embedded within the application. The specific server and agent architectures are described in the specific authentication solutions that follow. SSO Using Oracle Access Manager Since OAM is mainly a web application authentication solution, its components are all designed to protect applications in a typical web/HTTP environment. As illustrated in Figure 8-9, Oracle Access Manager (OAM) has three key components: Policy Manager The user interface for creating and managing SSO policies for the web applications that need to be protected. Access Server The component that accepts requests from the enforcement points for access control decisions (for example, password validations) and returns an allow/deny response to the enforcement point. Access Gate The enforcement component that is embedded in the application, typically as a web server filter where the end user application is deployed. ■ ■ ■ ■ ■ ■ FIGURE 8-8 Authentication Management 376 Part III: Identity Management Keep in mind that the backend policy store (LDAP) can be a physical LDAP server (for example, OID or Active Directory) or a virtual LDAP directory (for example, Oracle Virtual Directory). Enterprise SSO Solution Using Oracle eSSO Enterprise SSO (eSSO), shown in Figure 8-10, is an integration solution between an operating system or a thick client platform, so its components are designed to sit between the desktop and the application. The Oracle eSSO architecture has a component called the Logon Manager which sits on the user’s desktop to integrate the OS authentication (such as Windows Domain Authentication) with other desktop client applications or web SSO components such as OAM. Similar to OAM, it provides a management console for administrators to manage the eSSO policies. FIGURE 8-9 OAM Architecture FIGURE 8-10 Oracle eSSO Architecture Chapter 8: Architecting Identity Management 377 Strong Authentication and Fraud Prevention Using Oracle Adaptive Access Manager To enforce fraud and risk management, an application must be able to detect irregular access behaviors in an application and prevent potential frauds or risky scenarios. This kind of fraud detection is accomplished through intelligent metrics to score for a possible fraud candidate. The Oracle Adaptive Access Manager (OAAM) provides this solution along with strong authentication capabilities. The combination of strong authentication and fraud/risk management makes OAAM a powerful tool for highly sensitive web applications that have a high degree of exposure to attacks. For instance, OAAM is used by applications that sit on the public Internet and may be exposed to attacks from across the globe. For example, an online banking application can use OAAM and its risk monitoring capabilities to detect irregular and user behaviors and possibly prevent fraudulent transactions from occurring. Figure 8-11 illustrates the OAAM architecture. Federated Authentication Process Using Oracle Identity Federation A federation solution focuses on authentication, and in many cases authorization, of information transactions across enterprise boundaries. Figure 8-12 illustrates a sample federation request architecture in which a federation partner in domain A is trying to access information in a web application in domain B through a federated authentication process using Oracle Identity Federation (OIF). In this scenario, a requestor of information acts as the identity provider (IdP), and a server of information acts as the service provider (SP). The OIF IdP leverages federation standards, such as Security Assertion Markup Language (SAML) and Liberty, to propagate a user’s identity to the partner’s domain where the OIF SP accepts that request and evaluates the access request to the web application using a local set of federation and access policies. If the requester is a valid user, it allows the access to the federated web application and keeps the HTTP session alive as long as the federation token (for example, SAML token) is valid. FIGURE 8-11 OAAM architecture 378 Part III: Identity Management Centralized Database Authentication Using Oracle Enterprise User Security Oracle Enterprise User Security (EUS) is a solution offered as part of the Oracle Database (since version 9i) that uses an externalized LDAP server, such as Oracle Internet Directory, to externalize database user authentications. In addition to centralizing the authentication to the database, you can also centralize the authorizations for the authenticated sessions by mapping database roles and privileges to centralized LDAP groups. Figure 8-13 shows typical solution when the architecture needs to support end user authentication into the database tier, perhaps for additional access control using database roles/privileges or performing end user auditing on the database objects (tables, views, and so on). The Oracle products that enable this solution are the LDAP products (OID or OVD) and the EUS feature in the Oracle Database Server. The choice of LDAP product is yours based on your requirements. For instance, if you already have a physical LDAP server, you would simply layer the OVD product on top of the existing repository to make EUS work for your Oracle Database authentications. Authorization Management Managing and enforcing proper authorizations in an application are two of the most difficult and growing challenges in identity management. The topic of authorization management could fill an entire book for a comprehensive understanding of the solution. In this section, we will discuss a summary of this class of solution and the basic overview of how Oracle is approaching this space. As shown in Figure 8-14, two kinds of authorization management solutions exist: web access management and entitlement management. FIGURE 8-12 Federation architecture Chapter 8: Architecting Identity Management 379 Web access management is a solution to perform authorization checks on resources with a particular URI pattern (for example, xxxx/xxx/xx/pattern.*). This type of authorization is considered coarse-grained and works on web applications that are neatly partitioned using unique URLs, which are then mapped toward roles and privileges in the LDAP server. This solution is useful for protecting application access at high levels, where the policies are adjacent to SSO policies. The Oracle product that allows such coarse-grained authorizations is the same product that provides SSO functionality to web applications: Oracle Access Manager. FIGURE 8-13 Centralized database authentication FIGURE 8-14 Oracle authorization management 380 Part III: Identity Management The second kind of authorization management, entitlement management, provides the ability to authorize resources of any kind inside an application. The objects can vary from HTML pages, to Java objects, to Java 2 Platform Enterprise Edition (J2EE) beans, to data records, to user interfaces in middleware applications. This solution provides a much more flexible and sophisticated authorization framework for access control. The Oracle Entitlement Server (OES) provides this kind of fine-grained entitlement (authorization) management solution. Oracle Entitlement Server Architecture OES is a Java-based authorization framework that can integrate with Java and non-Java applications. The OES infrastructure comprises five essential components: Policy store A database holding all the entitlement and authorization policies. Policy administration point (PAP) The user interface where administrators can define policies around authorizations to resources. Policy information point (PIP) A provider of policy data to the decision and enforcement points. Policy decision point (PDP) A policy evaluation engine that decides whether to grant or deny access to a user based on the information it is provided. Policy enforcement point (PEP) The location where the user is either granted or denied access in the application. As the architecture shown in Figure 8-15 demonstrates, an application can integrate into the OES authorization decision-making framework in two ways. First, an application can choose to make a direct call from application to the OES PDP for a grant/deny decision for a certain user trying to execute a certain action on a specific resource. This approach requires an out-of-process call every time a protected resource is accessed and therefore can cause application performance degradation. Alternatively, OES offers an embedded policy decision point option for certain types of applications (for example, WebLogic servers, Oracle databases, Microsoft SharePoint servers, and so on) where components known as security modules can embed themselves as part of the application platform and make fast decisions without leaving the boundaries of the application’s policy enforcement point. Installing a security module for your application relieves you of the responsibility of knowing how your application communicates with the OES components. OES is also changing the fundamental shape of access architectures by allowing for the separation of enforcement points from decision points. This separation allows any future application to reuse a huge repository of existing business and information privacy policies and therefore significantly lowers the time and cost of application development. And maintenance is easier since making changes to policies no longer require application code changes. A Developer’s View of OES Fine-grained access management is definitely on the rise in today’s application development space since building this kind of policy enforcement mechanisms into the foundation of any application makes it much more flexible and adaptive to changing enforcement policies. For example, in today’s non-OES world, application developers are hard coding statements like this: if (user.memberOf("Manager") { changeSalary(" "); } ■ ■ ■ ■ ■ Chapter 8: Architecting Identity Management 381 This is a classic example of embedding an access control decision inside the application. Instead, the method call could have been protected using the following code: if (isAccessAllowed( user, policyId, action ) { changeSalary(" "); } The benefit of the second approach is that tomorrow you could make changes to your policy of granting Manager access to calling the changeSalary() method. Perhaps you may want to add the Executive role to be able to access that method as well. Using an OES approach, you can offload the actual policies inside OES policies, which can be changed without affecting the application. The only responsibility of the application will be to know the policy identifier to the appropriate policy it wants to enforce. Also, as XACML is being adopted, you can start using declarative policy using the XACML constructs to make requests to the OES server. Role Mining and Management Role mining is the ability to introspect and inventory all roles that exist in applications in the enterprise. Once the roles have been mined, they can then be processed, analyzed, and consolidate into a single set of logical business roles that are mapped to enterprise access policies that define the access to different applications based on their business roles. FIGURE 8-15 OES component architecture 382 Part III: Identity Management Role management is another fast-growing space in identity management, since more enterprises are looking to automate identity provisioning policies–based functional business roles that represent their day-to-day responsibilities. The Oracle role management solution is delivered by the Oracle Role Manager (ORM), which is an end-to-end mining, analytics, and management product for all roles across the enterprise. ORM leverages a strong integration with the user provisioning solution (OIM) to execute the provisioning of accounts and roles in different systems based on policies defined within ORM. The functional architecture for ORM is shown in Figure 8-16. As Figure 8-16 illustrates, ORM is the central rule and policy engine for deciding who belongs to what business roles, which then trigger access provisioning rules in OIM to execute the provisioning processes. From a pure technical perspective, ORM is a type of rules engine that focuses and optimizes business rules around enterprise and technical roles. It can store “static” roles that use a membership list approach to manage assignments to roles. ORM can also use attributes and other identity information to dynamically assign business and technical roles to users. The second approach is more popular since it requires less administrative work to manage role assignments. Role mining and management is a logical next step after implementing a user provisioning solution for an identity management architecture that is intended to automate processes and reduce risk of noncompliance with governance policies. ORM does allow exceptions and exception handling, which are mechanisms that override the central rules in case of temporary escalations or allowable one-off cases. For example, an exception could be granting administrative privileges to an external contractor, hired to perform critical repair work on a server. However, the number of exceptions should not grow so large that it starts looking like a new rule—in which case, you should probably create a new rule. In general, ORM projects are data intensive and should be properly planned up front to determine the scope of the implementation. It is unwise to try to mine the entire enterprise for role information at the first phase of the implementation. Instead, taking a more targeted approach, such as mining one application at a time, makes more sense and makes designing the business roles/hierarchies easier to handle. It is reasonable to expect an imperfect role management design FIGURE 8-16 ORM functional architecture Chapter 8: Architecting Identity Management 383 on the first pass of the project, since the ORM architecture factors ongoing changes to design without impacting the applications in a negative manner. As you extend your role management solution to support new applications and new enterprise domains, you will inevitably and continuously refine your roles and hierarchies in ORM. Summary One of the main reasons this chapter was written was to emphasize the importance of understanding identity management from the perspective of the problem. As mentioned in the introduction, you may be tempted to jump right into building the solution without fully understanding the consequences of that solution path. Unfortunately, when it comes to identity management problems, the challenge lies not in figuring out a solution to the problem but in deciding which solution to use. As engineers, we can always fit and configure products and technologies to solve short-term and immediate problems. However, this chapter encourages you to put on your architect hats before you start implementing specific solutions, such as User Provisioning or Directory Management, to ensure that your implementation design solves not just your immediate needs, but aligns with a longer term view of managing identities and enforcing application security. . Management Centralized Database Authentication Using Oracle Enterprise User Security Oracle Enterprise User Security (EUS) is a solution offered as part of the Oracle Database (since version. Architecture FIGURE 8-10 Oracle eSSO Architecture Chapter 8: Architecting Identity Management 377 Strong Authentication and Fraud Prevention Using Oracle Adaptive Access Manager To enforce fraud and risk management,. application and prevent potential frauds or risky scenarios. This kind of fraud detection is accomplished through intelligent metrics to score for a possible fraud candidate. The Oracle Adaptive