Selecting the Provider Working with Service Providers

Developing with the User and Role API 25-13

25.3.6.5 Configuring a Custom Connection Pool Class

To use a custom connection pool, you must provide the fully qualified class name of the custom connection pool class, as follows: factEnv.putOIDIdentityStoreFactory.ST_CONNECTION_POOL_CLASS, oracle.security.idm.providers.stdldap.JNDIPool; For related information, see Section L.6, Failure to Connect to the Embedded LDAP Authenticator.

25.3.7 Configuring the Provider when Creating a Store Instance

The IdentityStore configuration affects the store object and all objects that are created using this store instance. A configuration parameter commonly used with the store is ST_SUBSCRIBER_NAME, which is the only start-time property accepted here. All the runtime properties can be supplied during identity store creation. Continuing with the earlier example in Section 25.3.6, Configuring the Provider when Creating a Factory Instance which created a factory instance, this code creates a handle instance to the store. IdentityStore oidStore = null; Hashtable storeEnv = new Hashtable; Creating the store instance storeEnv.putOIDIdentityStoreFactory.ST_SUBSCRIBER_NAME, dc=us,dc=oracle,dc=com; oidStore = oidFactory.getIdentityStoreInstancestoreEnv;

25.3.8 Runtime Configuration

Earlier, in Section 25.3.6, Configuring the Provider when Creating a Factory Instance and Section 25.3.7, Configuring the Provider when Creating a Store Instance , we demonstrated how to perform configuration when creating an instance. To facilitate adding and modifying properties at runtime, the User and Role APIs also provide a Configuration class. The Configuration instance can be obtained from the store instance using the IdentityStore.getStoreConfiguration API call. Properties can be modified using the configuration object. Only runtime properties can be modified using this approach, and the effect is visible only at runtime. This example sets the RT_USER_SEARCH_BASES property: StoreConfiguration conf = oidStore.getStoreConfiguration; conf.setProperty“RT_USER_SEARCH_BASES”, “dc=us,dc=oracle,dc=com”;

25.3.9 Programming Considerations

This section contains tips for working with providers and provider artifacts. Note: Directories require that you supply a valid subscriber name. For Oracle Internet Directory, you can supply the STsubscriber name as either a proper DN or as the nickname of the realm. 25-14 Oracle Fusion Middleware Application Security Guide

25.3.9.1 Provider Portability Considerations

To ensure that your application is portable when switching providers say, from OpenLDAP provider to Oracle Internet Directory provider or the converse, follow these guidelines when working with the User and Role API:

1. Use only the corresponding oracle.security.idm.UserProfile constants

to refer to user properties. Avoid using native names which are not portable across identity repositories. For example, if the application needs to obtain a user’s login name, fetch it using the UserProfile.USER_NAME constant: Property prop = usrprofile.getPropertyUserProfile.USER_NAME; 2. For obvious reasons, UserProfile constants are provided for most standard user properties but not for all possible properties. If the application needs to obtain all the properties of a user generically, use the following code: UserProfile upf = null; Obtain the user profile from user object. User object can be obtained using search get the properties supported for given user in currently configured repository List proplst = store.getUserPropertyNames; String[] proparr = String[] proplst.toArraynew String[proplst.size]; get all properties of the user PropertySet pset = upf.getPropertiesproparr; 3. When creating search filters, do not use native wild card characters directly in your search filter string. Instead, use the SimpleSearchFilter.getWildCardChar method. This will fetch the correct wild character based upon the underlying provider. For example, the API will return for say a database provider and return for the Oracle Internet Directory provider. SmpleSearchFilter sf = m_identityStore.getSimpleSearchFilter attrName, SimpleSearchFilter.TYPE_EQUAL, null; sf.setValue filterStringWithoutWildcard+sf.getWildCardChar; 4. If your application accepts user-supplied filter strings with a predefined wild card character, apply the following conversion on the filter while generating the User and Role API filter: User supplied filter which assumes “” as the wildcard character String userDefinedFilter = ................. SmpleSearchFilter sf = m_identityStore.getSimpleSearchFilter attrName, SimpleSearchFilter.TYPE_EQUAL, null; userDefinedFilter = userDefinedFilter.replaceall, sf.getWildCardChar; sf.setValueuserDefinedFilter; The line in bold converts the user-supplied filter to the generic User and Role API filter format.