Code for CSF Operations Example 1: Java SE Application with Wallet Store

24-14 Oracle Fusion Middleware Application Security Guide JpsContextFactory.getContextFactory.getContext.getServiceInstanceCredentialSt ore.class; The latter call is shown in Section 24.7.2, Example 1: Java SE Application with Wallet Store .

24.7.4 Example 3: Java EE Application with LDAP Store

This example uses the same Java EE application used earlier in Example 2. The only difference is that the credential store is LDAP-based and not file wallet based. You need to configure the following properties in the domain-level jps-config.xml file: ■ root name property name=oracle.security.jps.ldap.root.name value=cn=OracleJpsContainer ■ farm name property name=oracle.security.jps.farm.name value=cn=OracleFarmContainer The configuration of the LDAP store in jps-config.xml is as follows: jpsConfig serviceProviders serviceProvider name=credstore_ldap_provider class=oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider descriptionPrototype LDAP-based CSF providerdescription serviceProvider serviceProviders serviceInstances serviceInstance provider=ldap.credentialstore.provider name=credstore.ldap property value=bootstrap name=bootstrap.security.principal.key property value=cn=wls-jrfServer name=oracle.security.jps.farm.name property value=cn=jpsTestNode name=oracle.security.jps.ldap.root.name property value=ldap:mynode.us.mycorp.com:1234 name=ldap.url serviceInstance serviceInstances jpsContexts default=appdefault jpsContext name=appdefault serviceInstanceRef ref=credstore_ldap_instance jpsContext jpsContexts jpsConfig The highlighted lines define the LDAP parameters necessary to locate the credentials. Developing with the Credential Store Framework 24-15

24.8 Best Practices

In a clustered environment, use the Credential Store Mbean API over the Credential Store Framework API to create, retrieve, update, and delete credentials for an application. If you are simply reading credentials, however, either API can be used. 24-16 Oracle Fusion Middleware Application Security Guide 25 Developing with the User and Role API 25-1 25 Developing with the User and Role API This chapter describes how to work with the API for user and role management. Prior to using this information, it is strongly recommended that you familiarize yourself with the context in which the API is used. For details, see: ■ Chapter 19, Developing Secure Applications with Oracle Platform Security Services ■ Section 19.2.2, The User and Role API This chapter contains these topics: ■ Introduction to the User and Role API Framework ■ Summary of Roles and Classes ■ Working with Service Providers ■ Searching the Repository ■ User Authentication ■ Creating and Modifying Entries in the Identity Store ■ SSL Configuration for LDAP-based User and Role API Providers ■ The User and Role API Reference ■ Developing Custom User and Role Providers ■ The User and Role SPI Reference

25.1 Introduction to the User and Role API Framework

The User and Role API framework allows applications to access identity information users and roles in a uniform and portable manner regardless of the particular underlying identity repository. The repository could be an LDAP directory server such as Oracle Internet Directory, Active Directory from Microsoft, or Oracle Directory Server Enterprise Edition, or could be a database, flat file, or some other custom repository. Note: The User and Role API is deprecated and may be withdrawn in a future release. Your new applications should be developed on the Identity Governance Framework. Plan to migrate existing applications to the Identity Governance Framework in a future release. For details, see the Oracle Fusion Middleware Identity Governance Framework ArisID API Developers Guide. 25-2 Oracle Fusion Middleware Application Security Guide This API framework provides a convenient way to access repositories programmatically in a portable way, freeing the application developer from the potentially difficult task of accounting for the intricacies of particular identity sources. The framework allows an application to work against different repositories seamlessly. An application can switch between various identity repositories without any code changes being required. Supported operations include creating, updating, or deleting users and roles, or searching users and roles for attributes or information of interest. For example, you may want to search for the e-mail addresses of all users in a certain role. You can use a basic usage model without container integration or a usage model with container integration that allows your code to be portable. When the application is intended to run in the context of an Oracle WebLogic Server container, the principal class should be cast to weblogic.security.principal.WLSUserImpl. A Note about Using the User and Role API As a general rule of thumb, authentication should only be performed by authentication providers, not through the User and Role API. Additionally, it is recommended that authentication providers be configured with the connect DN of a user that does not have write privileges.

25.1.1 User and Role API and the Oracle WebLogic Server Authenticators

The User and Role API is automatically configured to use the first Oracle WebLogic Server authenticator and does not require any special configuration. F Note, however, that configuration is required if the User and Role API is going against other authenticators. The API can access data only from the first LDAP authenticator listed in an Oracle WebLogic Server domain. When more than one authenticator is present, the precedence is determined by their control flag priority. If both have the same priority, the first one is picked. Any LDAP authenticators below the first one on the list are not accessed. About Concurrent Use of WebLogic APIs Your application should not try to use both the User and Role API and the WebLogic LDAPAuthenticator API such as EmbeddedLDAPAuthenticator, OracleInternetDirectoryAuthenticator, OracleVirturalDirectoryAuthenticator to work on entries in the same LDAP server concurrently. To understand why, consider two LDAP clients, both with caching enabled, that access the same LDAP server; one is deleting entries, and the other tries to use the deleted entries. Note: These APIs are not meant for authentication or authorization functions, but for maintaining identity information. Note: The following are required to invoke the User and Role API: ■ The identity store is LDAP-based ■ The domain administration server is up and running