Bug 595482 - User that exists in both ldap and rhq displays ldapgroups when using rhq login
User that exists in both ldap and rhq displays ldapgroups when using rhq login
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: No Component (Show other bugs)
4.2,4.3
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Sunil Kondkar
:
Depends On:
Blocks: jon24-ldap
  Show dependency treegraph
 
Reported: 2010-05-24 14:56 EDT by Corey Welton
Modified: 2012-03-01 11:24 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:50:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a patch that fixes the problem (8.89 KB, patch)
2010-07-23 13:39 EDT, John Mazzitelli
no flags Details | Diff
a patch that fixes the problem (10.31 KB, patch)
2010-07-23 14:06 EDT, John Mazzitelli
no flags Details | Diff

  None (edit)
Description Corey Welton 2010-05-24 14:56:08 EDT
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:
Comment 1 Charles Crouch 2010-07-19 21:26:11 EDT
Documentation issue to prevent admins from getting into this position https://bugzilla.redhat.com/show_bug.cgi?id=616253
Comment 3 John Mazzitelli 2010-07-23 13:39:36 EDT
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"
Comment 4 John Mazzitelli 2010-07-23 13:54:42 EDT
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"
Comment 5 John Mazzitelli 2010-07-23 14:00:41 EDT
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.
Comment 6 John Mazzitelli 2010-07-23 14:06:37 EDT
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
Comment 7 John Mazzitelli 2010-07-23 17:33:05 EDT
patch pushed to release-3.0.0 branch: 1f9e0e91b5ca6c5be60bf12197e17ec95aac6160
Comment 8 Simeon Pinder 2010-07-25 21:23:16 EDT
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.
Comment 9 Sunil Kondkar 2010-07-26 08:53:22 EDT
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.
Comment 10 Corey Welton 2010-08-12 12:50:44 EDT
Mass-closure of verified bugs against JON.

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