One of the requests I had recently, was to build a test plan for the IM:IG Continuous Update Web Service (aka "Live Notification"). (IM=CA Identity Manager, IG=Identity Governance). This is a web service between two (2) J2EE Servers (JBOSS/WIldfly) that keeps IG Universes (master/model) aware of any changes in the IM solution or managed endpoints from IM.
This is a useful web-service, that not only allows integration between these two (2) components, but is necessary for consistent data to be shared between the solutions.
While it is possible to scale test the complete integrated solution, it does require both IM & IG solution be dedicated during the exercise. This challenge may impact project time lines when attempting to measure performance or isolate issues, where project team resources may be focused on their own activities.
Example of IG WSDL for IM Live Notification:
To assist the the above challenge, a process was built using two (2) Identity Suite r14.2 virtual appliances, Jmeter 4.x and a couple of JVM switches (to emulate network proxy).
Validated that IM:IG integration was working correctly first.
Example of working process before introduction of Jmeter Proxy Recorder;
To test this integration, a review of various processes was used to confirm access and identify an OS port proxy process.
1) Validate that the IG Web Service was available for use with the SOAPUI tool (see below WSDL)
2) Validate that traffic is view-able (using WireShark) and able to see expected content (SOAP XML Body)
3) Review various network proxy processes. Discarded a few until arriving at workable process with little configuration change.
Add these two (2) JVM Switches to IM Wildfly Startup: -Dhttp.proxyHost=192.168.242.1 -Dhttp.proxyPort=18888
- If on the vApp, may directly edit the file /opt/CA/VirtualAppliance/custom/IdentityManager/jvm-args.conf
- Where the IP address where Jmeter is running (with proxy recorder enabled) & the Jmeter port.
- Jmeter may be executed from the user's workstation (assuming no network/firewall connectivity issues) or directly on the Server itself.
Using the above process, we are able to use Jmeter 4.x either on the workstation or deployed on the vApp Server (using config userID). If the process is working well, using the IM UI, it is possible to "test" the IM:IG connection, and capture that result within Jmeter proxy recorder.
Below example is the basic configuration needed to leverage the Jmeter Proxy Recorder.
- Create a Thread Group (right click on Test Plan) - rename it
- Create a Recorder (right click on Test Plan)
- Add two (2) Listeners under Recorder (right click on Recorder) of "View Results Tree/View Results in Table"
- Update the "Target Controller" field on the Recorder feature, to the above Thread Group Name.
- Update the "Grouping" field on the Recorder feature, to "Put each group in a new controller"
- Then click the recorder's green Start Icon. If JDK 1.8.x or later is available, then a temporary CA certificate will be generated and a popup will appear.
Testing the IM:IG basic connectivity and if being recorded in Jmeter.
- Exercise the full use-cases; and watch the Jmeter Listeners fill up with information.
After all use-case testing is complete with the web-service.
- Stop Jmeter Proxy Record; and then clean up the resulting test plan to your liking.
- This process would have built 95% of your test plan; and you will only need to adjust a few items.
Before results of executing the test plan:
- Viewing a record in IG Entity Browser before making a change with Jmeter.
Copy the SOAP Body, that was captured from Jmeter to NotePad++, and adjust a few fields, then re-copy into a new line item for Jmeter to test.
The IM:IG web service appears to submit two (2) transactions:
- One for user record updates; then followed by a membership of provisioning roles update.
Note: The above SOAP body has GUID values that appear to be generated on-the-fly. For a production test plan, these will need to be managed within the Jmeter Test plan. Otherwise, leave these for now, as there is no hard dependency on validation.
Note2: If you have Jmeter on the same Server as IM, you may wish to disable the JVM switches for IM now, before continuing.
After updating the Jmeter Test plan with the new information, execute it via first "GREEN ARROW" icon.
- Use the Listeners of "View Results Tree/View Results in Table" to ensure that the test plan is working.
- Use the double "BROOM w/GEAR" icon to remove previous results, to retest.
Then we see the following information updated in IG Universe - master/model.
Additional Notes: Errors seen using iptables routing.
Do not forget to disable the JVM switches after JMeter Proxy Recorder is disabled.
Ensure JMeter Proxy Recorder is Listening (if on workstation)
I have enclosed the Jmeter Test Plan (it is XML format) for the vApp demo package.
I am also enclosing soap bodies of the IM:IG integration that was captured.
BONUS - Capture secure web services for a test plan.
Add in two additional JVM switches: -Dhttps.proxyHost=192.168.242.146 -Dhttps.proxyPort=18888
Add the JMeter temporary CA cert to the Java Keystore used by the Server (Apache or Wildfly/JBoss)
List current CA Certs in the Java Keystore: keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts
Backup a copy of the cacert file: cp -r -p cacerts cacerts.before.jmeter.key.added
May wish to have a readable version of the cacerts:keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts > view_cacerts_before.txt
View the Jmeter temporary CA cert under the Jmeter bin folder: ls -lart /home/config/apache-jmeter-4.0/bin/
Import this Jmeter temporary CA cert in to the Java Keystore: (Note: Every time you restart Jmeter, it will generate a new temporary CA cert).
keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -file /home/config/apache-jmeter-4.0/bin/ApacheJMeterTemporaryRootCA.crt
Restart IM (Wildfly) Server with the new JVM switches for HTTPS (secure web traffic).
- Ensure Jmeter is running still with the same temporary CA cert.
Open the IM UI and change the IG port to 443 and Secure; then test.
- Confirm success in IM UI and within Jmeter.
Exercise the same IM:IG use-case for Live Notification, using the secure HTTPS port for IG.
Done. We have now captured the secure transaction for the two (2) server components, to allow us to build a Jmeter test plan.
- Note: This process may also be useful for troubleshooting web-services, or using the Connector Factory module to build dynamic connectors to web services, e.g. IM and CA APIGW (Layer7) connectors.
Please leave feedback if you find this valuable.
If you have connection issues between IM:IG for first time, walk through these steps:
Order that appeared to work 100%:
1) Update IME with the Smart Provisioning XML (IME Roles&Tasks)a. May enable extra IM hidden web service tasks but not required.
2) Delete any prior IME WebService for IMRCMa. This will remove any older objects or changes not required. (per known issue doc in bookshelf)
3) Create IG Universe with IdentityMinder connector & select Register for 1st time.a. This will send a submission of Create/Modify Web Service to IM (VST)b. Allow this to fail. (assumes no f/w issues) i. Note: May import a previously mapped IdentityMinder XML (to avoid retyping; very useful)c. Pause here
4) Via IM UI, select the IMRCM Web Service, update hostname/port credentialsa. Use TEST buttonb. Ensure this is successful.
5) Return to IG UI, and unselect “register” IG Web Service (it is done)a. Continue with IG IdentityMinder connector i. Will now report success.
6) When IG Universe IdentityMinder connector is complete, start first Importa. Monitor via IG UI Workflow for 100% completion.
7) Return to IM UI, select Modify Usera. Update any user attribute being mapped.b. View in VST, that transaction is being sent to IG
8) Return to IG UI Entity Browsera. View both the model/master of the Universeb. Confirm that the user record was updated.
I am now attempting to build a Jmeter Test Plan for IM:IG integration.o Allow both the IM team and IG team to continue to work independently without requirement one team to halt efforts, during initial performance and use-case validation.- Setup two (2) vApp Identity Suite using the pre-built demo package (allows additional data to be populated)o Note: Review if demo configuration for IM:IG integration is using incorrect ports of 80 (instead of 8080/8082)o Update IM on node1 to point to IG on node2 Each vApp has independent Oracle XE DB.