9780071754170 Chapter 4 Oracle Fusion Middleware Platform Security Services and Identity M

Download 9780071754170 Chapter 4 Oracle Fusion Middleware Platform Security Services and Identity M

Post on 27-Oct-2015




1 download

Embed Size (px)


Fusion Middle Ware Security Servicees


<ul><li><p>Oracle Fusion Middleware 11g Architecture and Management by Reza Shafii, Stephen Lee and Gangadhar Konduri </p><p>Oracle Press. (c) 2011. Copying Prohibited. </p><p>Reprinted for Shiv Shankar Mahalingam, Hewlett Packard </p><p>shiva-shankar.mahalingam@hp.com </p><p>Reprinted with permission as a subscription benefit of Skillport, http://skillport.books24x7.com/ </p><p>All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or other forms without written permission is prohibited. </p></li><li><p>Chapter 4: Oracle Fusion Middleware Platform Security Services and Identity Management </p><p>This chapter introduces the Oracle Platform Security Services (OPSS), which is a set of services used by all Fusion Middleware layered components. OPSS is built on top of the standards-based WebLogic Server security services, which we reviewed in Chapter 2. In this chapter, we explore the various services within OPSS and discuss the ways in which they can be used to secure enterprise applications. As we will see, when the overall life cycle of an enterprise application is considered, the key objective of OPSS is to provide the right level of abstraction, the right tools for the different persons involved, and the right methodology to properly implement, deploy, and maintain the application. </p><p>This chapter also introduces the full set of products within the Oracle Identity Management suite and reviews their dependencies on OPSS and other Fusion Middleware products to complete the overall picture of Fusion Middleware security. It is important to note that middleware security and identity management are broad subjects. The intent of this chapter is to give an introductory treatment of these subjects in the context of Fusion Middleware components rather than a comprehensive coverage. </p><p>Introduction to Oracle Platform Security Services </p><p>Oracle Platform Security Services (OPSS) provides a security platform for both Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications. As a platform-independent and application-server-independent layer, OPSS expands beyond the application server security providers to include features such as Credential Store Framework, Audit Framework, and User &amp; Role API, which we will review in this chapter. At development time, OPSS services can be directly invoked from the developer environment (for example, Oracle JDeveloper) to help developers create the necessary security artifacts for their applications. In the runtime environment, systems and security administrators can access OPSS services for configuration purposes through Enterprise Manager Fusion Middleware Control (Enterprise Manager) and command-line tools such as WebLogic Scripting Tool (WLST). Application and business owners can manage authorization policies through the OPSS Oracle Authorization Policy Manager (APM). All of these features are properly integrated into each stage of the application life cyclefrom development to packaging of the application; from deployment to administration; and from testing to production. Please note that although OPSS is designed to be application server independent, we will discuss it in the context of WebLogic Server only. </p><p>Architecture Overview </p><p>Built on top of WebLogic Server security services, OPSS provides a rich API for application security integration. Underneath, WebLogic Servers service provider interface (SSPI) layer delivers a set of pluggable security providers for flexible and custom implementations of a particular security service. It also allows OPSS to integrate with the security repositories, including flat files, LDAP directories, and database servers. Figure 4-1 shows the high-level OPSS architecture. </p><p>OracleFusionMiddleware11gArchitectureandManagement</p><p>ReprintedforHP/shivashankar.mahalingam@hp.com,HewlettPackard OraclePress,TheMcGrawHillCompanies,Inc.(c)2011,CopyingProhibited</p><p>Page 2 / 21</p></li><li><p> Figure 4-1: Oracle Platform Security Services architecture </p><p>Identities, Identity Store, and Authentication Providers </p><p>A domain identity store must be configured in order for OPSS to recognize any end users. OPSS leverages WebLogic Server authentication providers to define where the identity store is. When not integrated with an external Single Sign-On system, these authenticators validate user credentials through mechanisms such as username/password and digital certificates. They also allow user attributes and group information for the user to be retrieved from the identity store. Applications running in the domain can query user profile and group information from the identity store via the User &amp; Role API, which we will be discussing later on in this chapter. </p><p>Out of the box, the DefaultAuthenticator, also known as WebLogic Authentication Provider, is configured to leverage the embedded LDAP server as described in Chapter 2. Just like with a standard LDAP server, users and groups can be created within the embedded LDAP server. However, this server is only recommended for use in development environments where the number of users is below 10,000 entries and the number of groups is below 25,000. The reason for this is that the embedded LDAP server lacks the robustness, performance, and scalability of a production-quality LDAP server such as Oracle Internet Directory. </p><p>OPSS comes with a set of predefined authentication providers for username/password-based authentication and a set of identity assertion authentication providers for use with certificates or security tokens. Oracle Fusion Middleware also ships with turnkey providers that work with Oracle Identity Management components out of the box, including Oracle Internet Directory, Oracle Virtual Directory, and Oracle Access Manager. The configuration of the OPSS providers can be performed through the WebLogic Server admin console as well as WLST. </p><p>Figure 4-2 shows a typical application and its relationship with the identity store. </p><p> Figure 4-2: Authentication flow with the identity store </p><p>OracleFusionMiddleware11gArchitectureandManagement</p><p>ReprintedforHP/shivashankar.mahalingam@hp.com,HewlettPackard OraclePress,TheMcGrawHillCompanies,Inc.(c)2011,CopyingProhibited</p><p>Page 3 / 21</p></li><li><p>Policies and the Policy Store </p><p>The key to the OPSS lies in its policy model consisting of permissions, entitlements, application roles, application policies, and the various mappings and relationships among these objects. We will discuss the details of these objects and the overall application policy model later on in the chapter. The OPSS policy store serves as the repository for all these security artifacts. OPSS supports file-based, LDAP-based, and RDBMS-based policy stores. During the development phase, all the application policies are stored in an XML-based policy store named jazn-data.xml. When an application is deployed using Enterprise Manager or WLST, these application policies are deployed in the domain policy store automatically. The out-of-the-box domain OPSS policy store is file based. However, in a production environment, an LDAP-based or RDBMS-based policy store is desirable to provide better performance, backup, and high availability. </p><p>The policy store configuration is done at the domain levelimplying that for every domain, there can only be one OPSS policy store. Using Enterprise Manager, the policy store configuration can be done through the Security Provider Configuration page under the Security menu at the domain level. Figure 4-3 shows the configuration page. </p><p> Figure 4-3: The OPSS Security Provider Configuration page in Enterprise Manager </p><p>Enterprise Manager also supports migration of OPSS policy data from a file-based or LDAP-based policy store to another LDAP-based policy store. This process is also known as reassociation, which can be done through Enterprise Manager or WLST. Migration of policies is needed in scenarios where an entire domain or a single application is migrated from one domain to another, thus requiring policies to be migrated from one policy store to another. For example, a domain might be promoted from a staging to a production environment, or a new version of an application may be pushed from staging to production where an older version of the application already exists. To ensure the integrity of the policies, the reassociation logic searches the target LDAP and looks for a match for each policy within the source policy store. If a match is found, the matching policy is updated. If no match is found, the policy is copied and migrated as is. The migration can be done at the global level, where all the policies in the domain are migrated, or at the application level, where only policies for a specific application are migrated. The OPSS policy store reassociation capabilities provide a convenient method for migrating policies in development-to-production or test-to-production scenarios. </p><p>NoteThe administration of identity data in any LDAP-based identity store is done outside of OPSS and not through Oracle Fusion Middleware. An enterprise LDAP server is typically a part of the overall enterprise identity management infrastructure where identity administration is being handled. We will discuss some of these identity management components in the context of Oracle Identity Management later in this chapter. </p><p>OracleFusionMiddleware11gArchitectureandManagement</p><p>ReprintedforHP/shivashankar.mahalingam@hp.com,HewlettPackard OraclePress,TheMcGrawHillCompanies,Inc.(c)2011,CopyingProhibited</p><p>Page 4 / 21</p></li><li><p>Credentials and the Credential Store </p><p>Application developers often have to deal with the storage of credentials such as username and password combinations, tickets, tokens, and public key certificates. To address these needs, OPSS provides a comprehensive Credential Store Framework, including a set of APIs and support for a file-based or LDAP-based credential store. </p><p>OPSS supports two types of credentials: a password credential consists of a username and password combination, and a generic credential encapsulates any customized data or arbitrary token, such as a symmetric key. The APIs allow applications to create, read, update, and manage these credentials, which are typically used to access an external application or an external repository such as databases or LDAP directories. </p><p>Figure 4-4 shows a typical application and its relationship with the credential store. </p><p> Figure 4-4: Credential Store Framework </p><p>Similar to the policy store, OPSS supports a default file-based credential store in the form of an Oracle Wallet. The recommended production setup is to leverage an LDAP-based or RDBMS-based credential store. In fact, when an LDAP-based or RDBMS-based repository is set up, OPSS treats the policy and credential store together using a single repository configuration, as shown in Figure 4-4. </p><p>User &amp; Role API </p><p>A key objective of OPSS is to provide an abstraction layer for application developers dealing with users and roles that doesnt require them to worry about the intricacies of the underlying repositories where users and roles are stored. Developers can therefore rely on the User &amp; Role API to access this information, which enables applications to work seamlessly against different repositories without any code changes to the application itself. The User &amp; Role API acknowledges the runtime configuration of the OPSS identity store. By default, it uses the first configured WebLogic Server authentication provider within the domains security realm. If more than one authentication provider exists, the precedence is determined by the control flag priority, and the higher-priority one is selected. At any time, the User &amp; Role API can only work with a single WebLogic Server authentication provider. </p><p>Figure 4-5 shows a typical application and its relationship with the identity store through the User &amp; Role API. </p><p> Figure 4-5: Application accessing the identity store with the User &amp; Role API </p><p>Audit Framework </p><p>The Fusion Middleware Audit Framework is an OPSS service designed to provide a centralized audit framework for the Fusion Middleware family of products. The framework provides audit services for Fusion Middleware Common </p><p>OracleFusionMiddleware11gArchitectureandManagement</p><p>ReprintedforHP/shivashankar.mahalingam@hp.com,HewlettPackard OraclePress,TheMcGrawHillCompanies,Inc.(c)2011,CopyingProhibited</p><p>Page 5 / 21</p></li><li><p>Infrastructure and Oracle SOA Suite components, including OPSS and web services. Some of the system components, such as Oracle Internet Directory and Oracle HTTP Server, are also integrated with the Audit Framework. However, the main objective of the Audit Framework is to provide a set of services for all Java EE components within Fusion Middleware and eventually to allow custom Java EE development to leverage this framework. In Fusion Middleware 11g, the Audit Framework is integrated with many Fusion Middleware Java EE components, including Oracle Access Manager and Oracle Identity Federation. Table 4-1 shows a partial list of components that are integrated with the OPSS Audit Framework. </p><p>Integration with the Audit Framework starts with the audit APIs, which allow applications to specify audit event details where appropriate. The audit event data is then pushed to the centralized audit repository, an RDBMS instance containing the audit schema created by the Repository Creation Utility (RCU). It is generally recommended that a dedicated RDBMS instance be used for audit purposes because the audit store is expected to be cumulative and will grow over time. </p><p>The Audit Framework allows each audit-aware component to define a set of events. Each event definition identifies the set of attributes with names and data types to be recorded as part of the audit event itself. A component audit policy is a declaration of which audit events and how the audit data will be captured. Audit policies of all the audit-aware components are centrally managed through Enterprise Manager or through WLST. Although the current audit framework is restricted for use by Oracle Fusion Middleware components only, Oracle may expose its functionality for enterprise applications deployed to a Fusion Middleware environment. </p><p>Once the audit data is collected in the audit repository, Oracle Business Intelligence Publisher (BI Publisher) can be used to view the audit data through predefined or custom reports. The audit data collected contains information about the time, component, operation, and user information for each audit event, thus allowing the data to be filtered and analyzed across different dimensions. In addition, Fusion Middleware Audit Framework supports the notion of an Execution Context Identifier (ECID), which is used to track the flow of a particular request through the various layers of the product stack, thus </p><p>Table 4-1: List of Products Supporting Fusion Middleware Audit Framework </p><p>Category Component Name </p><p>Platform n Oracle Platform Security Services </p><p>Oracle SOA Suite n Oracle Web Services Manager </p><p> Agents </p><p> Policy Manager </p><p> Policy Attachment </p><p>n SOA Suite Web Se...</p></li></ul>