Local user authentication

[td121136]

Hi, I noticed for local client authentication JBoss had introduced the "JBoss Local User SASL" mechanism which using the tokens. I'm not really understand this mechanism, does it means the mechanism only activate for the person who startup the JBoss AS? Because for my case the same the user account used to startup the JBoss AS might be sharable to few persons, but i don't want all of them granted with the same access, is there any possibilty to turn of this mechanism and force to used only the remote access?

[jaikiran]

See the section named "Local Clients" here https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault

[td121136]

Yup, i already read that post. In the post there is a sentence "...providing the local user running the server access using tools such as the CLI, the Maven plug-in, JBoss Tools etc..." in the Local Client section.

Is that means the same person started the server, or any local users (same host) who have access to those tools? I'm confuse, just want to be sure on this.

[dlofthouse]

All users with access to {jboss.home}/standalone/tmp/auth or {jboss.home}/domain/tmp/auth depending on which mode you are running will be able to access the server using the local authentication mechanism.

If you have multiple users sharing the same account used to start JBoss then they potentially have the ability to override any configuration you choose to set.

However you do not mention which version you are running, check the security realm definition for the ManagementRealm - if there is a <local /> element in there you can remove it to switch off the authentication.

[td121136]

Sorry, i'm using JBoss version 7.1.1.Final standalone mode, i already checked in the "jboss-as-config_1_2.xsd" schema, there doesn't seems like any <local> element i can make use. The default standalone.xml doesn't have the <local> tag as well.

[dlofthouse]

In that case I think there are two real options: -

1. Build a later tag of AS7 or WildFly that does include the configuration option.
2. Change the ownership of the 'auth' folders mentioned above to a different user, maybe even root to disable the mechanism.

[td121136]

I will test with the 2nd option because right now it is impossible for me to do such major upgrade. thanks Darran for your suggestion.

[td121136]

I had tested few scenarios as below:

Scenario #1 (Start JBoss as User A, auth ownership belongs to User A)

1) Start JBoss using User A.

2) Start JConsole using User A, able to see and access the JMX MBeanServer process.

3) Start JBoss CLI using User A, able to connect without username and password authentication.

4) Start JConsole using ROOT, able to see and access the JMX MBeanServer process.

5) Start JBoss CLI using ROOT, able to access it without username and password authentication.

For scenario above, does it means ROOT user can always access JConsole & JBoss CLI eventhough it is not the one startup the server?

Scenario #2 (Start JBoss as User A, change auth ownership: "chmod root:root auth")

1) Start JBoss using User A.

2) Start JConsole using User A, able to see and access the JMX MBeanServer process.

3) Start JBoss CLI using User A, connection required username and password authentication.

4) Start JConsole using ROOT, able to see and access the JMX MBeanServer process.

5) Start JBoss CLI using ROOT, connection required username and password authentication.

For above scenario, since the auth ownership change to ROOT user, user A not suppose to direct access the JConsole right?

The ROOT user owned the auth this time, but how come username and password still required for JBoss CLI access?

Scenario #3 (Start JBoss as ROOT user, Change auth ownership back to User A)

1) Start JBoss using ROOT user.

2) Start JConsole using ROOT user, able to see and access the JMX MBeanServer process.

3) Start JBoss CLI using ROOT user, able to access it without username and password authentication.

4) Start JConsole using User A, can't see and access the JMX MBeanServer process.

5) Start JBoss CLI using User A, able to access it without username and password authentication.

I really confused about how's the local mechanism work, hope can have a full documentation on it.