Creating the Provider Instance

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. Developing with the User and Role API 25-15

25.3.9.2 Considerations when Using IdentityStore Objects

Keep the following considerations in mind when coding your applications. Thread Safety The current IdentityStore implementations are not thread-safe. The User and Role API assumes that the store instances are not generally shared among threads. If the store instance is shared among threads, the application code must take care to handle any required thread safety issues. There are trade-offs between thread safety and performance. Use cases that need to implement thread safety must be willing to consider the performance implications of doing so. One Store Instance per Session In applications such as Delegated Administration Server, each session corresponding to one logged-in user can change its own createsearch bases and various other runtime settings; these are defined as runtime properties in the User and Role API. The IdentityStore object encapsulates all these settings and changes its runtime behavior accordingly. For this reason, the rule of one IdentityStore instance per session is enforced.

25.3.10 Provider Life cycle

A given provider exists for the lifetime of the factory instance created for that provider. The life of a factory instance ends whenever the close API is called on that instance. When the provider instance ends, all the objects that were created using that instance become invalid, and subsequent API calls on those objects return unanticipated output. Similar considerations apply to IdentityStore instances.

25.4 Searching the Repository

The User and Role API provides two types of query functions: ■ functions that return a single identity ■ functions that return a list of identities This section describes searches and related tasks you can accomplish with the API, and provides details on specifying search parameters: ■ Searching for a Specific Identity ■ Searching for Multiple Identities ■ Specifying Search Parameters ■ Using Search Filters ■ Searching by GUID Note: ■ Factory instances are thread-safe while this is not the case with IdentityStore instances. ■ It is best practice to cascade close server connections and explicitly delete objects and instances no longer in use.