Bug 669476

Summary:	Principal and credentials can not be auto-discovered for SOA-P instance due to wrong user and role properties file name
Product:	[Other] RHQ Project	Reporter:	Larry O'Leary <loleary>
Component:	Plugins	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.0.0	CC:	jshaughn, loleary
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	JON 2.4 SOA-P 5
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Larry O'Leary 2011-01-13 18:49:50 UTC

When a SOA-P instance is auto-discovered, the JMX principal and credentials can not be determined because the wrong file name is used when attempting to locate the user and role properties file.

From org.jboss.on.common.jbossas.JBossASDiscoveryUtils.getJmxInvokerUserInfo(File configDir) we are assuming the user and role property files will be named using the securityDomain. In both EAP and SOA-P, the securityDomain for the JMX invoker service is "jmx-console". However, the user and role mapping property files in SOA-P are simply named soa-users.properties and soa-roles.properties as defined in the login-config.xml in SOA-P. What this results in is the failure to find either file during discovery and therefore the initial principal and credentials are left null.

As there does not appear to be any requirement that the user and role mapping property files be named anything specifically, I would say that such a naming requirement seems to be a blind requirement by the AS plug-in.

I suppose there is no easy/safe way out of this situation but I would suggest that we attempt the following:

 1. Look up the security domain as we do currently and attempt to parse the property files as we do now
 2. If 1. fails, use the common "jmx-console" string as the security domain
 3. If 2. fails, use the common "soa" string as the security domain
 4. If 3. fails, set the principal/credential to admin/admin

Comment 1 Larry O'Leary 2011-01-13 20:53:57 UTC

After more thought, it appears that the plug-in is actually looking things up incorrectly.

For AS plug-in, if we are using JMX, then we should be looking up the securityDomain in jmx-invoker-service.xml (like we are) and then getting the path to the users/roles property files from login-config.xml using the application policy which matches the security domain.

For AS5 plug-in, we would do the same as the AS plug-in if we are needing JMX but seeing that we are using ProfileService, we should be looking up the securityDomain in profileservice-jboss-beans.xml and then getting the users/roles property files from login-config.xml.

Then, we could try 2, 3, and default to 4 if all else fails. Keeping in mind that this will not work in every instance but would be broadening the success in many use-cases and lower the impact of future changes/platforms breaking the ability for auto-discovery to get a hold of a valid user/password.