Authorization Required Security Features

19-2 Oracle Fusion Middleware Application Security Guide 2. The developer defines Java EE logical roles and assigns them privileges through security constraints, all through configuration in standard Java EE deployment descriptors. 3. The components are assembled and combined into an Enterprise Archive EAR file. As part of this process, the assembler specifies options appropriate to the environment. 4. The assembler defines application-level security constraints and resolves potential conflicts between module-level configurations. 5. The EAR file is deployed to Oracle WebLogic Server. As part of the deployment process, the deployer may map Java EE roles to deployment users and roles. 6. The system administrator maintains and manages the deployed application. This task includes creating and managing roles and users in the deployment environment as required by the application customers. For finer-grained code-based or subject-based access control using Java 2 or JAAS features, the traditional steps include: 1. The developer identifies any resources that may be accessed and must be protected as appropriate. 2. The developer defines permissions to protect these resources. 3. The developer implements code for runtime authorization checks. 4. The system administrator maintains any necessary policy configuration to enforce the desired permissions. Policy provisioning should be completed prior to runtime. Oracle ADF and OPSS provide these enhancements: ■ At Design Time - modeling of application roles, defining resources as permissions, and assigning permissions to roles. Application credential management is supported, for example, ADF connections can store credentials in the Credential Store Framework during design time. ■ At Deployment Time - policy and credential migration options are available ■ Post-deployment, the administrator performs essential tasks such as mapping application roles to enterprise users or groups which are reflected at run-time

19.1.2 Challenges of Securing Java Applications

Java developers face some challenges in developing secure applications: ■ The Java EE standard does not define any API for fine-grained authorization, credential mapping, role mapping, auditing, or integration with single-sign. ■ Developers need to acquire in-depth security knowledge at the expense of focusing on application business logic. ■ There is no consistent security experience across platforms. For example, custom security solutions often develop their own security framework, which is often not portable across platforms. ■ Custom solutions for securing Java EE applications often lack support for large enterprise security deployments. Developing Secure Applications with Oracle Platform Security Services 19-3 Such key aspects as manageability, availability, scalability, and reliability are often missing from custom solutions.

19.1.3 Meeting the Challenges with Oracle Platform Security Services

Oracle Platform Security Services OPSS is a portable security services abstraction layer that provides a robust security framework that saves development time and effort. OPSS enhances traditional Java EE development in many respects: ■ Provides basic security services such as authentication, authorization, auditing, role management, and credential management. ■ Allows developers to focus on the application logic. ■ Provides the same services that Oracle Fusion Middleware products get: – OPSS is the security platform for Oracle Fusion Middleware components, such as Oracle WebLogic Server, Oracle Entitlement Server, Oracle SOA Suite, and Oracle WebCenter. ■ Is standards-based and enterprise-ready: – Stress-tested to support enterprise deployments. – Interoperable across different LDAP servers and single sign-on SSO systems. – Certified on Oracle WebLogic Server. ■ Provides the same set of APIs for all types of applications in-house, third-party, Oracle Fusion. ■ Optimizes development time with by using abstraction layers. ■ Application maintenance is simplified since security rules can be changed without affecting application code. ■ Enables legacy and third-party security provider integration. OPSS support for Identity Management IdM includes: ■ A lightweight infrastructure that allows customers to build and deploy small to mid-size applications ■ A plug-in interface to IDM systems: – Applications build against OPSS can be plugged to a centrally deployed Identity Management system – Customers can scale their applications to switch to a centrally deployed Identity Management system – No code changes are required in the application when switching between IdM systems.

19.1.4 OPSS Architecture

Figure 19–1 shows the basic components of the OPSS architecture. There are specific APIs for most of the features discussed earlier in this manual that are available for use by application developers. Underlying SPIs service provider interfaces, mentioned briefly in Section 1.2, OPSS Architecture Overview, are mostly invisible to application developers and administrators.