A common scenario that arises with WebCenter Content: Imaging is one where an external LDAP directory such as Oracle Internet Directory or Active Directory is used along with the embedded WebLogic LDAP ‘DefaultAuthenticator’. Because the weblogic user is often needed in the DefaultAuthenticator for logging into WebLogic Admin console, the typical solution is to edit the jps-config.xml file and add the virtualize flag.
One 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.
<!– JPS WLS LDAP Identity Store Service Instance –>
<serviceInstance name=”idstore.ldap” provider=”idstore.ldap.provider”>
<property name=”idstore.config.provider” value=”oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider”/>
<property name=”CONNECTION_POOL_CLASS” value=”oracle.security.idm.providers.stdldap.JNDIPool”/>
<property name=”virtualize” value=”true” />
</serviceInstance>
However, 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 a bit much. 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.
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 being user) 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 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 once 500 users are accessing the Imaging Task Lists, or contributing and searching content in Content Server. The best scenario in production is to just be using an 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 dropping the DefaultAuthenticator, create a Credential Map in WCC that will map 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. If you do forget to add this Credential Map before removing the Default Authenticator, it can be added manually on the file system. A file named ConnectionsSecurityData.hda can be added (or edited, if it already exists).
<domain>/ucm/cs/data/users/connections
The contents of the file for the Credential Map use hda format. Note that the header line below shows 11.1.1.7. This can be change to match other hda files in your content server system. Likewise, the blDateFormat should be set to match other hda files in your environment. However – if you create the Credential Map before dropping the Default Authenticator, you will not have to do this manual step at all.
<?hda version="11gR1-11.1.1.7.0-idcprod1-130611T200110" jcharset="UTF8" encoding="utf-8"?>
@Properties LocalData
blDateFormat=M/d{/yy}{ h:mm[:ss]{ a}}!mAM,PM!tAmerica/Chicago
@end
@ResultSet FMWAdministratorsCredentialsMap
2
cmIn
cmOut
|#all|
%%
FMWAdministrators
Administrators
FMWAdministrators
admin
@end
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. 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 admin user to that group, whether is it weblogic or other user. WCC will block access to the Admin Server unless the sysmanager group is located for the logged in 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. This provider should be moved to the top of the provider list in the WebLogic security realm.
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
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. Note that the conjunction uses “or”, so the Administrators group can remain in place. Another reason to leave Administrators in the condition is to have it there if you choose to re-enable the Default Authenticator for some reason.
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')
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.
In addtion, don’t forget to edit the jps-config.xml file to turn off virtualize=true. This step should be done before removing the default authenticator. The path to the jps-config.xml file is:
<domain>/config/fmwconfig/jps-config.xml
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 Server to verify that you can login to the WLS console as weblogic.
Updating Imaging security
Imaging may be configured to use the Administrators group as well, meaning that an update will need to be done here as well. To determine if the Administrators group name is used for security access in Imaging, certain tables will need updating to change the group name from Administrators to FMWAdministrators.
Query the Imaging tables definition_security, system_security, and document_security to check on what groups are being used. If they need updating, update queries can be used. For example, the following update queries are needed to replace the Administrators group with FMWAdministrators.
update definition_security set name = 'FMWAdministrators' where name = 'Administrators' and securitymember_type LIKE 'GROUP'; update document_security set name = 'FMWAdministrators' where name = 'Administrators' and securitymember_type LIKE 'GROUP'; update system_security set name = 'FMWAdministrators' where name = 'Administrators' and securitymember_type LIKE 'GROUP'; commit;
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.
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
Another warning about using a different password for the weblogic user is that if the managed servers are using a boot.properties file, this file may need to be updated. If the weblogic user in Active Directory or OID has a different password than that which was in the DefaultAuthenticator, the boot.properties file will need to be updated.
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. 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 with the Imaging and WebCenter Content instances.
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.