Bug 669476 - Principal and credentials can not be auto-discovered for SOA-P instance due to wrong user and role properties file name
Principal and credentials can not be auto-discovered for SOA-P instance due t...
Status: NEW
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
3.0.0
Unspecified Unspecified
low Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-13 13:49 EST by Larry O'Leary
Modified: 2014-07-08 13:55 EDT (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
Description Larry O'Leary 2011-01-13 13:49:50 EST
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 15:53:57 EST
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.

Note You need to log in before you can comment on or make changes to this bug.