A common scenario that arises with WebCenter Content Suite of products is one where an external LDAP directory such as Oracle Internet Directory or Active Directory is used along with the embedded WebLogic LDAP ‘DefaultAuthenticator’. But by default only users/groups from the primary authenticator (the first authenticator in the WLS provider list) are available to the Oracle Platform Security Services (OPSS). However, when the virtualization setting is enabled, this enables the identity store to merge both the external LDAP and embedded LDAP roles, thus solving the problem where Oracle Platform Security Services (OPSS) will only use the top provider that is defined in the list in the WLS Security Realm.
To view whether the setting is enabled or not, Enterprise Manager can be used.
1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.
2. Expand, if necessary, the area Identity Store Provider, and click the "Configure" button to display the page Identity Store Configuration.
3. In the Custom Properties section, if turned on, the virtualize setting will be displayed.
![idstore-virtualize]()
The side effect of this is added complexity in the lookup of user groups, since additional work is then needed for authorizing users. Given that most customers only use the DefaultAuthenticator for one user (weblogic), turning on virtualize for one user is not recommended. The impact of using virtualize can be significant, depending on the complexity of the external LDAP directory. The solution then is to determine how to avoid using the DefaultAuthenticator at all, and to only use the external LDAP directory for all user roles including the WebLogic Console Administrator.
Turning off the Default Authenticator can be simple with Oracle Internet Directory, but only if the OID administrator will create a user named "weblogic" (or whatever admin user name is chosen) and add that user to a group called "Administrators" in OID. In the case of Active Directory, this is not as simple. In Active Directory, the "Administrators" group has special meaning, just like it does in WebLogic. There is a naming collision. AD admins are loathe to add any user to the Administrators group, since that opens up the domain to that user. This would mean a "weblogic" user would have full access to AD, and no AD administrator is likely to give the nod to that request.
The solution to this naming issue with the Administrators group in WebLogic is to use a different LDAP group, such as FMWAdministrators, to separate the need for Active Directory to protect the Administrators group from application users, and for WLS and application users to have full access. Once an FMWAdministrators group exists in Active Directory, the XACML (eXtensible Access Control Markup Language) settings in WebLogic can be updated to use FMWAdministrators instead of Administrators for allowing access to the WLS console. Of course, the “weblogic” administration user needs to be a member of the FMWAdministrators group for this to work properly.
The primary reason to remove the Default Authenticator is to improve performance. The virtualize=true setting is easy to turn on but adds complexity to the user authorization process. In development and test environments using this setting may not show any performance degradation, but in production this can lead to unwanted side effects in your applications as the LDAP structure becomes increasingly complex. The best scenario in production is to use your external enterprise LDAP directory, such as OID or Active Directory, and turn off the Default Authenticator.
WebCenter Content pre-requisite steps
Removing the DefaultAuthenticator for use with WebCenter Content and WebCenter Content: Imaging requires a set of steps that must be performed in order to maintain proper access to content. Like WebLogic and Active Directory, WebCenter Content also uses the Administrators group for assigning elevated access. Before removing the WebLogic DefaultAuthenticator create a Credential Map in WebCenter Content that maps FMWAdministrators to both the Administrators and admin roles.
Example Credential Map name: FMWAdministrators
Example Credential Map contents:
![]()
This mapping allows the content server to make use of the FMWAdministrators group for admin users. This map must be set for use in the JpsUserProvider, otherwise it will not take effect. The provider.hda file must be updated to have a line like the following. For the JpsUserProvider, the location of the provider.hda file is at this path:
<domain>/ucm/cs/data/providers/jpsuserprovider
Keep in mind if WebCenter Content is clustered, this path will be on the shared file system, not on local disk. This file must be edited in a text editor. The following line can be added anywhere in the section "@Properties LocalData".
ProviderCredentialsMap=FMWAdministrators
Upon restart, the JpsUserProvider in WebCenter Content will begin mapping the role FMWAdministrators. An important point to make here is that you will want to add this Credential Map prior to removing the Default Authenticator, otherwise you will have to add the map manually on the file system.
The other requirement for WebCenter Content when removing the Default Authenticator is that the Admin Server link will not work in WCC unless the admin user (e.g. weblogic) is a member of either Administrators or sysmanager groups. WebCenter Content blocks access to the Admin Server unless the user is associated to the Administrators or sysmanager group. In the case of Active Directory, you will likely not be using Administrators, which is why the FMWAdministrators group is needed in the first place. Thus the only other option is to create a group called “sysmanager” in the external LDAP setup (AD or OID) and assign the desired WebCenter Content Admin user to that group, whether is it weblogic or another user.
![]()
Imaging Solution Accelerators and SOA Roles
If using the Imaging Accounts Payable Solution Accelerator, steps must be taken to update the SOA application roles in Enterprise Manager. Various roles for SOA rely on the Administrators group, thus the addition of FMWAdministrators is also needed for SOA to function as expected when the Administrators group is no longer in use.
add FMWAdministrators to these in SOA app roles. Out of the box, soa has all of these set to “Administrators”.
SOAAdmin
SOAOperator
SOAMonitor
SOAAuditAdmin
SOAAuditViewer
SOADesigner
This can be done through Enterprise Manager or WLST.
Updating the SOA role using Enterprise Manager:
Log in to Enterprise Manager (e.g. http://hostname:7001/em).
Click on soa-Infra
Click on the Soa Infrastructure dropdown and navigate to security -> Application Roles
Click on the Search button in the middle of the screen (this will display the SOA App roles)
Add the Group to each of the roles listed above.
Updating the SOA role using WLST:
The WebLogic scripting tool can also be used for this step. Change the paths to the Middleware home as needed.
![]()
Conclusion
The virtualize=true option is a powerful feature, but often not needed and adds an additional layer of complexity to security. In the event you have multiple external LDAP providers, you may require that the virtualization setting is enabled. However, even in that situation, it is often best to remove the DefaultAuthenticator because instead of virtualizing two sets of LDAP directory roles, the embedded WLS LDAP directory also will be virtualized. The WLS embedded LDAP directory can be removed safely and give a performance bump to user interactions not only within the Imaging and WebCenter Content instances but throughout the entire ECM product.
Lastly, the performance between Imaging and WebCenter Content can be further boosted by changing the user caching settings on WebCenter Content. By default, WCC has a UserCacheTimeout of 1 minute (UserCacheTimeout=60000). This time can be increased to a higher value and make the link between Imaging and the WCC repository faster, since authorization will only need to be done at a higher interval. To increase the UserCacheTimeout on the Content Server, add an entry to the config.cfg file using milliseconds as the value. To set the timeout to 1 hour, use the following:
UserCacheTimeout=3600000
This will make the Content Server return requests faster to Imaging, as well as reduce load on the LDAP directory servers.
If virtualization is still needed with AD...
For customers that require multiple security providers the virtualize=true flag will still need to be set. When this is the case, the Default Authenticator should still be removed to reduce the workload of resolving groups in the OPSS layer. This is especially important if the users have many group associations (i.e. 50 assigned groups).
When virtualize=true is enabled, a parameter called max.search.filter.length is hardcorded as 500 bytes. When making nested group membership calls, number of (uniquemember=group_dn_1 OR uniquemember=group_dn_2 OR ...) filter values are limited by this max filter length parameter. With user having around 100 roles assigned, there are around 10-15 ldap search calls made for a single user. Each LDAP search call may only take 50 milliseconds, but because the calls are done serially and for each individual security provider, performance problems arise.
However, most LDAP providers can support filters of much larger length. Increasing the max.search.filter.length to bigger value can reduce number of nested search calls significantly.
To benefit from this setting, a patch needs to be applied to the oracle_common home. Once the patch is applied, the setting needs to be added to the jps-config.xml file. To add this setting in Enterprise Manager, use the following steps. Note that this setting will only have value if virtualize=true is already enabled.
1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.
2. Expand, if necessary, the area Identity Store Provider, and click the "Configure" button to display the page Identity Store Configuration.
3. In the Custom Properties section, verify the virtualize=true flag exists. If not then the max.search.filter.length is not required.
4. Add the parameter max.search.filter.length=20000
The base bug for the max.search.filter.length setting is below. This bug is fixed in 11.1.1.9 and 11.1.1.5. Backports to 11.1.1.6 and 11.1.1.7 have been requested at this time.
Bug 17302469 - MAX.SEARCH.FILTER.LENGTH IS NOT CONFIGURABLE FOR LIBOVD PROVIDER
The side effect of this is added complexity in the lookup of user groups, since additional work is then needed for authorizing users. Given that most customers only use the DefaultAuthenticator for one user (weblogic), turning on virtualize for one user is not recommended. The impact of using virtualize can be significant, depending on the complexity of the external LDAP directory. The solution then is to determine how to avoid using the DefaultAuthenticator at all, and to only use the external LDAP directory for all user roles including the WebLogic Console Administrator.
Turning off the Default Authenticator can be simple with Oracle Internet Directory, but only if the OID administrator will create a user named "weblogic" (or whatever admin user name is chosen) and add that user to a group called "Administrators" in OID. In the case of Active Directory, this is not as simple. In Active Directory, the "Administrators" group has special meaning, just like it does in WebLogic. There is a naming collision. AD admins are loathe to add any user to the Administrators group, since that opens up the domain to that user. This would mean a "weblogic" user would have full access to AD, and no AD administrator is likely to give the nod to that request.
The solution to this naming issue with the Administrators group in WebLogic is to use a different LDAP group, such as FMWAdministrators, to separate the need for Active Directory to protect the Administrators group from application users, and for WLS and application users to have full access. Once an FMWAdministrators group exists in Active Directory, the XACML (eXtensible Access Control Markup Language) settings in WebLogic can be updated to use FMWAdministrators instead of Administrators for allowing access to the WLS console. Of course, the “weblogic” administration user needs to be a member of the FMWAdministrators group for this to work properly.
The primary reason to remove the Default Authenticator is to improve performance. The virtualize=true setting is easy to turn on but adds complexity to the user authorization process. In development and test environments using this setting may not show any performance degradation, but in production this can lead to unwanted side effects in your applications as the LDAP structure becomes increasingly complex. The best scenario in production is to use your external enterprise LDAP directory, such as OID or Active Directory, and turn off the Default Authenticator.
WebCenter Content pre-requisite steps
Removing the DefaultAuthenticator for use with WebCenter Content and WebCenter Content: Imaging requires a set of steps that must be performed in order to maintain proper access to content. Like WebLogic and Active Directory, WebCenter Content also uses the Administrators group for assigning elevated access. Before removing the WebLogic DefaultAuthenticator create a Credential Map in WebCenter Content that maps FMWAdministrators to both the Administrators and admin roles.
Example Credential Map name: FMWAdministrators
Example Credential Map contents:
|#all|, %% FMWAdministrators, Administrators FMWAdministrators, admin
This mapping allows the content server to make use of the FMWAdministrators group for admin users. This map must be set for use in the JpsUserProvider, otherwise it will not take effect. The provider.hda file must be updated to have a line like the following. For the JpsUserProvider, the location of the provider.hda file is at this path:
<domain>/ucm/cs/data/providers/jpsuserprovider
Keep in mind if WebCenter Content is clustered, this path will be on the shared file system, not on local disk. This file must be edited in a text editor. The following line can be added anywhere in the section "@Properties LocalData".
ProviderCredentialsMap=FMWAdministrators
Upon restart, the JpsUserProvider in WebCenter Content will begin mapping the role FMWAdministrators. An important point to make here is that you will want to add this Credential Map prior to removing the Default Authenticator, otherwise you will have to add the map manually on the file system.
The other requirement for WebCenter Content when removing the Default Authenticator is that the Admin Server link will not work in WCC unless the admin user (e.g. weblogic) is a member of either Administrators or sysmanager groups. WebCenter Content blocks access to the Admin Server unless the user is associated to the Administrators or sysmanager group. In the case of Active Directory, you will likely not be using Administrators, which is why the FMWAdministrators group is needed in the first place. Thus the only other option is to create a group called “sysmanager” in the external LDAP setup (AD or OID) and assign the desired WebCenter Content Admin user to that group, whether is it weblogic or another user.
Removing the Default Authenticator
Much of the steps followed below are similar to Oracle Business Intelligence documentation on "Using Alternative Authentication Providers". However, some of the BI-specific users and groups are not needed. To view the official documenation used by BI customers, see the link below. http://docs.oracle.com/cd/E23943_01/bi.1111/e10543/privileges.htm#BABFHAIC Backup config.xml file Backup the system before deleting the Default Authenticator. To do so, make a copy of <domain-home>/config directory so that it may be restored if needed. Create the Active Directory or OID authenticator This has likely already done if you are considering removal of the Default Authenticator. If not already, this provider should be moved to the top of the provider list in the WebLogic security realm and the services restarted. Identify or Create Essential Users Required in external LDAP Create the following essential groups in Active Directory or OID. weblogic - This username may be different if you have defined another username in the embedded LDAP directory in WebLogic. OracleSystemUser - This user is needed for Oracle Web Services Manager (OWSM). Create Essential Groups in external LDAP To remove the Default Authenticator, certain groups must exist in the external LDAP directory. FMWAdministrators - This group name can be anything you choose. AdminChannelUsers AppTesters CrossDomainConnectors Deployers Monitors Operators OracleSystemGroup sysmanager (This is the group needed for WebCenter Content access to the admin server.) After creating the users and groups in the Active Directory, the default weblogic user (or username that you’ve chosen) should be made a member of FMWAdministrators group. The OracleSystemUser should be a member of OracleSystemGroup. Note: The WebLogic security realm provides the capability to export an ldif file of all users and groups defined in the embedded LDAP directory. This can provide a method of exporting all users and groups at once. However, the ldif produced will need modification if used for creating users and groups in Active Directory or OID. To get an ldif file for the DefaultAuthenticator, in Weblogic Console, click on Security Realms -> myrealm -> Provider -> DefaultAuthenticator -> Migration -> Export. Update WebLogic to use FMWAdministrators for the "Admin" role Login to the WebLogic Admin Server console. Click on Security Realms -> myrealm -> Roles and Policies -> Global Roles Expand "Roles". On the row with the role "Admin", click "View Role Conditions". Click the "Add Condition" button. Select "Group" from the Predicate List drop down. Click "Next". In the "Group Argument Name" text field, enter "FMWAdministrators". Click the "Add" button and then click "Finish". At this point the “Admin” role for WLS console will be assigned to users who are members of either Administrators or FMWAdministrators. Once the DefaultAuthenticator has been removed then the Administrators group should also removed unless you want to allow your external LDAP Administrators admin access to the WebLogic Console.
Imaging Solution Accelerators and SOA Roles
If using the Imaging Accounts Payable Solution Accelerator, steps must be taken to update the SOA application roles in Enterprise Manager. Various roles for SOA rely on the Administrators group, thus the addition of FMWAdministrators is also needed for SOA to function as expected when the Administrators group is no longer in use.
add FMWAdministrators to these in SOA app roles. Out of the box, soa has all of these set to “Administrators”.
SOAAdmin
SOAOperator
SOAMonitor
SOAAuditAdmin
SOAAuditViewer
SOADesigner
This can be done through Enterprise Manager or WLST.
Updating the SOA role using Enterprise Manager:
Log in to Enterprise Manager (e.g. http://hostname:7001/em).
Click on soa-Infra
Click on the Soa Infrastructure dropdown and navigate to security -> Application Roles
Click on the Search button in the middle of the screen (this will display the SOA App roles)
Add the Group to each of the roles listed above.
Updating the SOA role using WLST:
The WebLogic scripting tool can also be used for this step. Change the paths to the Middleware home as needed.
export ORACLE_HOME=/opt/middleware/Oracle_SOA1
cd $ORACLE_HOME/common/bin
./wlst.sh
#connect to the SOA server
connect('weblogic','welcome1', 't3://hostname:7001')
#Add the new external group name to SOAAdmin role
grantAppRole(appStripe='soa-infra',appRoleName='SOAAdmin',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
grantAppRole(appStripe='soa-infra',appRoleName='SOAOperator',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
grantAppRole(appStripe='soa-infra',appRoleName='SOAMonitor',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
grantAppRole(appStripe='soa-infra',appRoleName='SOAASOAAuditVieweruditAdmin',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
grantAppRole(appStripe='soa-infra',appRoleName='SOAAuditViewer',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
grantAppRole(appStripe='soa-infra',appRoleName='SOADesigner',principalClass='weblogic.security.principal.WLSGroupImpl',principalName='FMWAdministrators')
Updating Imaging security
At this point, you will also want to run the mbean operation “refreshIpmSecurity” to make sure everything is updated in the Imaging managed server.
Login into Enterprise Manager.
Navigate down to the Imaging server under the Weblogic Domain Folder.
Once the right hand pane refreshes, click on the ‘Weblogic Server’ drop down menu and select ‘System MBean Browser’.
On the MBean Browser tree go to Application Defined MBeans –> oracle.imaging –> Server: IPM_server1 –> cmd –> cmd
Click on the ‘refreshIPMSecurity’ link on the right hand pane.
Press Invoke button.
In WebCenter Content: Imaging(IPM) all the existing security references to DefaultAthenticator users/groups that have not been duplicated in the external LDAP will need to be /replaced with external LDAP users/groups by walking through the System Security, Definition Security, and Application Document Security using the IPM UI. This must be performed before the DefaultAthenticator or virtualization have been removed.
Delete the DefaultAuthenticator
Before deleting the DefaultAuthenticator, verify that the Active Directory or OID users and groups show up in the WLS security realm. Click on the “Users and Groups” tab of the realm page to verify that the LDAP provider is finding external users and groups. Also log out of the WebLogic Console and attempt to log in as the new administrative user you have created in the external LDAP provider.
In addition, don't forget to turn off virtualize=true in Enterprise Manager. This step should be done before removing the DefaultAuthenticator.
1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.
2. Expand, if necessary, the area Identity Store Provider, and click the "Configure" button to display the page Identity Store Configuration.
3. In the Custom Properties section, if turned on, the virtualize setting will be displayed. Remove the setting.
Once that is verified, go to the Providers tab and check the box next to DefaultAuthenticator, and then click the "Delete" button.
Restart the WebLogic Admin/Managed Servers and verify that you can login to the WLS console as weblogic or whatever user you setup as the WLS Admin.
Note: If users or passwords are changed for the admin users referenced in credentials for web services, csf-key values will need to be updated. Credentials are used in keys for calling web services, so if a username or password change is made in AD, the credential stores need to be updated. Be aware of these. Imaging's AXF integration point can be used with web services that communicate with SOA, E-Business Suite, and PeopleSoft. If the password or usernames change, the keys must be updated to match.
Imaging: MA_CSF_KEY and basic.credential
SOA: basic.credential
EBS: SOAP user used by AXF.
execute fnd_vault.put('AXF','AXF_SOAP_USER','SOAP_PASSWORD');
PSFT: Integration Broker -> Node Configuration
If using a different user or password from the original weblogic user then the boot.properties file will need to be manually updated. Back this file up and replace the encrypted user and/or password with the new user/password. Once the services have been restarted this information will automatically be encrypted.
Additional warning: If using Active Directory, and the weblogic user is set to only be allowed logon from certain workstations/hosts, and WebLogic is running on Linux (or non-Windows), the WebLogic servers may fail to start because of a bind failure. The weblogic user cannot be restricted to specific "Logon Workstations", otherwise the error is difficult to locate. Run a manual ldapbind to test that the weblogic user can bind to AD. If it cannot bind, the issue may be due to a LDAP 531 error, meaning the user is restricted to logon only from certain machines. An example error of an ldapbind command is shown below:
ldap_bind: Invalid credentials ldap_bind: additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 531, v1db1
Verify Imaging and Content Server login work as expected
Login to Imaging to ensure that all applications show up as they did before when the DefaultAuthenticator was in place.
Login to the Content Server as the weblogic user and click on the username in the upper right. The FMWAdministrators role should appear, and the user should also have the "admin" role in the list. Verify that the sysmanager role also appears. To test that the Admin Server is opening correctly, go into the Administration menu and click "Admin Server".
Conclusion
The virtualize=true option is a powerful feature, but often not needed and adds an additional layer of complexity to security. In the event you have multiple external LDAP providers, you may require that the virtualization setting is enabled. However, even in that situation, it is often best to remove the DefaultAuthenticator because instead of virtualizing two sets of LDAP directory roles, the embedded WLS LDAP directory also will be virtualized. The WLS embedded LDAP directory can be removed safely and give a performance bump to user interactions not only within the Imaging and WebCenter Content instances but throughout the entire ECM product.
Lastly, the performance between Imaging and WebCenter Content can be further boosted by changing the user caching settings on WebCenter Content. By default, WCC has a UserCacheTimeout of 1 minute (UserCacheTimeout=60000). This time can be increased to a higher value and make the link between Imaging and the WCC repository faster, since authorization will only need to be done at a higher interval. To increase the UserCacheTimeout on the Content Server, add an entry to the config.cfg file using milliseconds as the value. To set the timeout to 1 hour, use the following:
UserCacheTimeout=3600000
This will make the Content Server return requests faster to Imaging, as well as reduce load on the LDAP directory servers.
If virtualization is still needed with AD...
For customers that require multiple security providers the virtualize=true flag will still need to be set. When this is the case, the Default Authenticator should still be removed to reduce the workload of resolving groups in the OPSS layer. This is especially important if the users have many group associations (i.e. 50 assigned groups).
When virtualize=true is enabled, a parameter called max.search.filter.length is hardcorded as 500 bytes. When making nested group membership calls, number of (uniquemember=group_dn_1 OR uniquemember=group_dn_2 OR ...) filter values are limited by this max filter length parameter. With user having around 100 roles assigned, there are around 10-15 ldap search calls made for a single user. Each LDAP search call may only take 50 milliseconds, but because the calls are done serially and for each individual security provider, performance problems arise.
However, most LDAP providers can support filters of much larger length. Increasing the max.search.filter.length to bigger value can reduce number of nested search calls significantly.
To benefit from this setting, a patch needs to be applied to the oracle_common home. Once the patch is applied, the setting needs to be added to the jps-config.xml file. To add this setting in Enterprise Manager, use the following steps. Note that this setting will only have value if virtualize=true is already enabled.
1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.
2. Expand, if necessary, the area Identity Store Provider, and click the "Configure" button to display the page Identity Store Configuration.
3. In the Custom Properties section, verify the virtualize=true flag exists. If not then the max.search.filter.length is not required.
4. Add the parameter max.search.filter.length=20000
The base bug for the max.search.filter.length setting is below. This bug is fixed in 11.1.1.9 and 11.1.1.5. Backports to 11.1.1.6 and 11.1.1.7 have been requested at this time.
Bug 17302469 - MAX.SEARCH.FILTER.LENGTH IS NOT CONFIGURABLE FOR LIBOVD PROVIDERAll content listed on this page is the property of Oracle Corp. Redistribution now allowed without written permission
