Development Phase Security Life Cycle of an Application

Integrating Java EE Application Security with OPSS 18-11 For complete details about developing security in an ADF application, see chapter 29 in Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework.

18.9 Integrating the Credential Store

Developers frequently are concerned with sensitive data necessary to operate the application or to access external services from it. The credential store, part of OPSS, is the repository of such data, and the CSF API allows an application accessing and operating on this data. Developers should not include clear text user names or passwords in applications; instead, this data should be stored in the credential store, and, when necessary, the application should access credentials programmatically using the CSF API. Administrators manage credentials using either the Fusion Middleware Control or OPSS scripts. Credentials are protected by code source permissions. Logically, credentials are grouped in maps or containers for a collection of credentials. Within a map, a credential is uniquely identified by its key. Thus, a credential is uniquely determined by a pair of map and key. It is recommended that the map name be the same as the application name to prevent name collision if multiple applications are deployed to the same domain and, therefore, use the same credential store. CSF is available for Java EE, Java SE, and C applications. For details about the credential store, see Chapter 24, Developing with the Credential Store Framework.

18.9.1 Guidelines for Using CSF

When working with CSF, a developer should follow the following guidelines: ■ Understand the CSF API. CSF is implemented by identifying the appropriate map and key names to use. This is particularly important in environments where multiple applications share the credential store. For details, see Section 24.6, Steps for Using the API. ■ Provision policies that allow access to credentials. These policies are kept in the policy store, which can be file-based system-jazn-data.xml or LDAP-based. Note the following important guidelines: – Application code that requires access to a credential must be packaged into the smallest possible jar. – That jar needs to be granted the CredentialAccessPermission on the specific map and key name with a specific set of actions. For details, see Section 24.3, Setting the Java Security Policy Permissions. – The grant must be specified in the application jazn-data.xml file, which is packaged with the application and migrated to the policy store when the application is deployed. Note: Developers should never change the security data kept in the source control. This recommendation includes not changing entitlements, application roles, the application role hierarchy, test enterprise roles, and test users. 18-12 Oracle Fusion Middleware Application Security Guide ■ In a clustered environment, use the Credential Store Mbean API over the Credential Store Framework API to create, retrieve, update, and delete application credentials. If, however, you are simply reading credentials either use either API. For details about MBeans, see Section E.2, Configuring OPSS Services with MBeans.

18.9.2 Cryptography

Oracle Security Developer Tools provide cryptographic building blocks necessary to develop basic tasks, such as secure messaging, and more complex ones, such as implementing a secure service-oriented architecture. These tools build upon the core foundations of cryptography, public key infrastructure, Web services security, and federated identity management, to provide: ■ Authentication, which assures the receiver that the information is coming from a trusted source. Authentication is typically achieved by using a Message Authentication Code MAC, a digital signature, or a digital certificate. ■ Confidentiality, which ensures that only the intended recipient of the message can read it. Confidentiality is typically achieved through encryption. ■ Integrity, which ensures that the received message has not been tampered. Integrity is typically achieved by using a cryptographic hash function. ■ Non-repudiation, which proves that a given sender actually sent a particular message. Non-repudiation is typically achieved by using digital signatures. For details about the Oracle Security Developer Tools, see Section H.1, OPSS API References, and Section 19.5, Using the Oracle Security Developer Tools.