Hi,
Hi,
We have seen that using “$JBOSS_HOME/bin/add-user.sh” script we can create Management & Application Users. Using “add-user.sh” script when we create users then the credentials of Management user is stored inside the “$JBOSS_HOME/standalone/configuration/mgmt-users.properties” and inside the “$JBOSS_HOME/standalone/configuration/mgmt-users.properties” file. Even though the passwords are encrypted still many administrators like to store their management credentials inside the Database rather than storing them inside the Database.
So here as part of this Demo we will see how to create a Database authentication “security-domain” and how to associate the “ManagementRealm” with the “DBAuthTest” security-domain. We will need to follow the below mentioned steps in order to achieve the same.
MySQL Database & Datasource configuration
First of all we will see what all configurations are needed at the Database end and the Datasource configuration.
Step1). Start the MySQL database and then create the following Tables with the required Data as mentioned:
CREATE TABLE PRINCIPLES ( principal_id VARCHAR(64) primary key,password VARCHAR(64)); CREATE TABLE ROLES ( principal_id VARCHAR(64),user_role VARCHAR(64),role_group VARCHAR(64)); Insert into PRINCIPLES values('adminUser','admin123'); Insert into ROLES values('adminUser','admin','admin');
You can insert more records in your database based on your requirement. I created only one Admin User.
JBossAS7 side configuration
Step2). Place the MySQL database driver “mysql-connector-java-5.1.13-bin.jar” inside the “$JBOSS_HOME/standalone/deployments” directory.
Step3). Now start your JBossAS7 standalone profile as following:
[userone@localhost bin]$ ./standalone.sh -c standalone-full.xml -bmanagement 10.10.10.10 -b 20.20.20.20
NOTE: You can start your Server in localhost address as well. Here i started the JBoss Management interface at 10.10.10.10 Address where as the public interface on “20.20.20.20”.
Step4). It’s time to create a DataSource. So lets start the JBossAS7.1.1.Final and then open the JBoss CLI utility “$JBOSS_HOME/bin/jboss-cli.sh” then run the following command in order to create MySQL DataSource as following:
[userone@localhost bin]$ ./jboss-cli.sh --connect --controller=10.10.10.10:9999 [standalone@10.10.10.10:9999 /] /subsystem=datasources/data-source="java:jboss/MySqlDS":add(jndi-name="java:jboss/MySqlDS",pool-name="MySqlPool",driver-name="mysql-connector-java-5.1.13-bin.jar",connection-url="jdbc:mysql://localhost:3306/testDB",user-name="root",password="redhat")
Once the above command executes successfully executes you will see the following kind of entry inside your “$JBOSS_HOME/standalone/configuration/standalone-full.xml” file (Inside the “[subsystem xmlns=”urn:jboss:domain:datasources:1.0″]” subsystem):
<datasource jndi-name="java:jboss/MySqlDS" pool-name="java:jboss/MySqlDS"> <connection-url>jdbc:mysql://localhost:3306/testDB</connection-url> <driver>mysql-connector-java-5.1.13-bin.jar</driver> <security> <user-name>root</user-name> <password>redhat</password> </security> </datasource>
Step5). Now we will create a Security-Domain inside the “[subsystem xmlns=”urn:jboss:domain:security:1.1″]” subsystem of your “$JBOSS_HOME/standalone/configuration/standalone-full.xml” file as following:
<security-domain name="DBAuthTest"> <authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> <module-option name="dsJndiName" value="java:jboss/MySqlDS"/> <module-option name="principalsQuery" value="select password from PRINCIPLES where principal_id=?"/> <module-option name="rolesQuery" value="select user_role, 'Roles' from ROLES where principal_id=?"/> </login-module> <login-module code="org.jboss.security.auth.spi.RoleMappingLoginModule" flag="optional"> <module-option name="rolesProperties" value="${jboss.server.config.dir}/test-roles.properties"/> <module-option name="replaceRole" value="false"/> </login-module> </authentication> </security-domain>
Step6). As you can see above that in the “RoleMappingLoginModule” configuration we passed a file “test-roles.properties” for mapping the database user to the authorization role. So we will need to now create a file with name “test-roles.properties” inside the following location
“$JBOSS_HOME/standalone/configuration/test-roles.properties”
and
“$JBOSS_HOME/domain/configuration/test-roles.properties”
#username=RoleName adminUser=admin
Step7). The Most important part now. We will edit the “$JBOSS_HOME/standalone/configuration/standalone-full.xml” file as well as “$JBOSS_HOME/domain/configuration/domain.xml” file <management> <security-realms> section as following sothat our custom security “DBAuthTest” can be associated with this ManagementRealm:
<security-realm name="ManagementRealm"> <authentication> <jaas name="DBAuthTest"/> </authentication> </security-realm>
Step8). Restart your JBossAS7 profile and then try to access the JBoss Console “http://10.10.10.10:9990/console” with the database table credential like
[userone@localhost bin]$ ./standalone.sh -c standalone-full.xml -bmanagement 10.10.10.10 -b 20.20.20.20
username: adminUser
password: admin123
.
.
Thanks
MiddlewareMagic Team
January 25th, 2013 on 5:50 am
Step 4 also edits a file using jboss-cli.sh. Pretty smooth. However, Step 5 and Step 6 require manual edits to the exact same file. If you have to edit it, anyway, you might as well do the manual edit in Step 4, too.
If you could do 4-6 all through jboss-cli.sh, that would be pretty helpful. It would lend well to automation and scalability.
July 12th, 2013 on 10:53 am
Are you sure the RoleMappingLoggingModule is even needed? Why did we create the ROLES table and specify the rolesQuery if we have to add the same user to the properties file? I thought maybe the second login module was for finding users not available in the first.
October 15th, 2013 on 12:36 pm
is there any way we can avoid test-roles.properties and user database query for the same. so that we can create users and roles from UI instead of hard coding in the properties file.
October 22nd, 2014 on 6:15 pm
Hi!
Great post, thanks!
However, I think that the use of the RoleMappingLoginModule is incorrect and confusing in the example.
As I have understood it, the file referred to by the “rolesProperties” module-option is _not_ regarded (by RoleMappingLoginModule) as containing username-to-rolename-mappings. Instead, referring to the example, that file *could* be used to map a value in the ROLES.user_role database column to another role name. For example, suppose the ROLES.user_role column had contained the value “AdminUserRole” (instead of, as now, “admin”). (Further suppose that you – for whatever reason – were unable to change “AdminUserRole” to “admin” in ROLES.user_role in the database). Then you could write “AdminUserRole=admin” in the “test-roles.properties” file to make the example work. However, since ROLES.user_role in the example already contains the required value – “admin” – there is no need to have any mapping in the “test-roles.properties” file.