Description of problem: If an acct ("joeuser") exists in both ldap and rhq, when someone logs in with rhq user/password pair, authentication is successful and ldap group still appears. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create ldap user "joetester" with password "password" 2. Associate ldap user "joetester" with an ldap group and associate that ldap group with an rhq role 3. Create rhq user "joetester" with password "newpassword" 4. Login to rhq with u/p pair from step 3. 5. View group/role info for this user Actual results: User "joetester" shows as associated with ldap group. Expected results: [14:50] <joseph> if the password exists in rhq, it should not presume it's an ldap users AT ALL [14:50] <joseph> that's a bug [14:51] <cswiii> alright [14:51] <joseph> a user must either be rhq-defined or ldap-defined, it should not be both Additional info:
Documentation issue to prevent admins from getting into this position https://bugzilla.redhat.com/show_bug.cgi?id=616253
Created attachment 434020 [details] a patch that fixes the problem this is a patch that can be applied to master to fix the problem. Its a new class file, plus a change to CustomJaasDeploymentService.java. To apply, save the file somewhere and "cat <patch file> | git am"
Here's what I think we need to do. Create a second JDBC JAAS login module - one that only checks to see if there is a principle for the user in the RHQ_PRINCIPAL table. If so, we know the user should only be authenticated with the DB. JDBC-1 login module does the full DB check (makes sure there is a principal in the DB and the password matches). JDBC-2 is a simpler check - just makes sure there is NOT a principal in the DB, we don't care about anything else. So, assume we have, in this order, in our JAAS login modules: JDBC-1, JDBC-2, LDAP. In this example, assume I have "rhqadmin" user defined in both the DB and the LDAP directory. Assume the DB also has the user "joe" and the LDAP directory has the user "bob": DB: rhqadmin, joe LDAP: rhqadmin, bob Here's how the flow through the JAAS login modules should work, assuming JDBC-1, JDBC-2 and LDAP is the order of the JAAS modules and assume I provided the correct password for all users (except unknownUser, assume that's a username that is in neither DB or LDAP): rhqadmin joe bob unknownUser =================================================== JDBC-1 PASS PASS FAIL FAIL JDBC-2 PASS PASS LDAP PASS FAIL --------------------------------------------------- result: LOGIN! LOGIN! LOGIN! REJECT! Notice JDBC-1 is not required to pass to continue, but JDBC-2 IS required to pass to continue on to the LDAP module. Here's what the flow would look like if I provided a bad password for the given user. Note that in this example for the rhqadmin user, I gave the password that doesn't match rhqadmin's DB password, but it does match the password for the rhqadmin user in LDAP (but as you see below, it doesn't matter because LDAP is never checked now for the rhqadmin user) rhqadmin joe bob unknownUser =================================================== JDBC-1 FAIL FAIL FAIL FAIL JDBC-2 FAIL FAIL PASS PASS LDAP FAIL FAIL --------------------------------------------------- result: REJECT! REJECT! REJECT! REJECT! Again, notice JDBC-1 is not required to pass to continue, but JDBC-2 IS required to pass to continue on to the LDAP module. In order to be able to do this, we need to set the proper jaas control flag (javax.security.auth.login.AppConfigurationEntry.LoginModuleControlFlag) for the two JDBC modules (one of REQUIRED, REQUISITE, SUFFICIENT, OPTIONAL) Here's the javadoc for those different settings: ---------- 1) Required - The LoginModule is required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list. 2) Requisite - The LoginModule is required to succeed. If it succeeds, authentication continues down the LoginModule list. If it fails, control immediately returns to the application (authentication does not proceed down the LoginModule list). 3) Sufficient - The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed down the LoginModule list). If it fails, authentication continues down the LoginModule list. 4) Optional - The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list. The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed. --------- Based on the above, JDBC-1 is "SUFFICIENT" and JDBC-2 is "REQUISITE"
opp... one thing wrong with that patch. According to the JAAS javadoc, and since our LDAP module is currently SUFFICIENT, any password (right or wrong) will pass LDAP authentication. I need to change the LDAP module to be REQUISITE.
Created attachment 434023 [details] a patch that fixes the problem attaching new patch, obsoleting the old one - I needed to make the LDAP module REQUISITE, instead of SUFFICIENT
patch pushed to release-3.0.0 branch: 1f9e0e91b5ca6c5be60bf12197e17ec95aac6160
With changes to auth, QA should also test basic LDAP auth still works in addition to the authz use cases outlined above. This just means that with a configured ldap integration and no "Group *" ldap settings configured that matching user accounts are still successfully created in RHQ.
Verified on Jon-2.4.0.GA_QA build#78. Tested on redhat directory server and windows active directory. If the same user exist in both ldap and rhq, user with username/password of rhq- user can login and the user is not shown as associated with ldap group. User with username/password of ldap user- cannot login to rhq. Also verified basic ldap test cases related to authorization.
Mass-closure of verified bugs against JON.