Bug 1542125

Summary: JBoss ON user's roles do not match LDAP mapping if user is logged in using REST API
Product: [JBoss] JBoss Operations Network Reporter: Filip Brychta <fbrychta>
Component: SecurityAssignee: Josejulio Martínez <jmartine>
Status: CLOSED ERRATA QA Contact: Filip Brychta <fbrychta>
Severity: high Docs Contact:
Priority: high    
Version: JON 3.3.9, JON 3.3.10CC: jmartine, loleary, spinder
Target Milestone: CR01Keywords: Triaged
Target Release: JON 3.3.11   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-16 17:06:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Filip Brychta 2018-02-05 15:52:50 UTC
The user's roles should match the LDAP mapping regardless of how users are logged in. This is the case with user logged in using JBoss ON UI. However, if the user is logged in using REST API this will not be the case.

Version-Release number of selected component (if applicable):
JBoss ON 3.3.10

How reproducible:
Always

Steps to Reproduce:
1. Create LDAP user (for instance: myTest) that does not belong to JON LDAP Group but belongs to some other LDAP groups;
2. In JBoss ON UI, logged in as "rhqadmin" user, change "All Resources" role to include JON LDAP Group (JON UI -> Administration -> Roles -> LDAP Group);
3. Also, add newly created LDAP user to "All Resources" role (JON UI -> Administration -> Roles -> Users;
4. Save the changes and log out;
5. Using newly created LDAP user and REST API log in to JBoss ON 
curl --user myTest:myTest http://jon3x-server.bc.jonqe.lab.eng.bos.redhat.com:7080/rest/resource/platforms.html

6. Confirm that LDAP user can see resources;
7. Using the same user (myTest) try to log in to JBoss ON UI;
8. Confirm that this user (myTest) does not have permission to see any of the resources;

Actual results:
JBoss ON user's roles match LDAP mapping only when user is logged in through JBoss ON UI; For users logged in via REST API this is not a case.


Expected results:
JBoss ON user's roles have to match LDAP mapping regardless of how user's are logged in.

Comment 2 Josejulio Martínez 2018-08-14 14:20:26 UTC
It looks like the default cache [1] that is used doesn't have any expiration time, it holds 1000 items and only removes elements from its cache when is out of space.

A jira's comment [2] confirms that there is two types of caches that can be assigned to the security-domain, the default (currently used) and "infinispan".

With this info, did the following changes to standalone-full.xml

a) Changed cache-type of Rest security-domain to infinispan:

- <security-domain name="RHQRESTSecurityDomain" cache-type="default">
+ <security-domain name="RHQRESTSecurityDomain" cache-type="infinispan">

b) Created a cache container inside subsystem infinispan
<cache-container name="security" default-cache="auth-cache">
  <local-cache name="auth-cache">
    <transaction mode="NONE"/>
      <eviction strategy="LRU" max-entries="50000"/>
      <expiration max-idle="200000" lifespan="30000"/>
  </local-cache>
</cache-container>


I reverted this commit [3] (reverted the revert) and did the following test:


1) With everything setup for ldap:
   user: myTest
   ldap group: jon-group 

   "All Resources Role" does not have jon-group in the "Assigned LDAP Groups"

2) Fetch platforms using REST API
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html

3) Confirms it shows 0 platforms
4) Add ldap group to "All Resources Role"
5) Wait for the cache expire (With my setup, 30 seconds since the first request in (2))
6 Fetch platforms using REST API
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
7) Confirm it shows all the platforms in JON 

This setup only requires to put back Simeon changes again (revert [3]) and update the standalone-full.xml file of the server.
The only caveat is that we can only have one cache like this in our config, because cache-type is hardcoded to cache-container = security; cache=auth-cache.

There should be a way to programmatically create the cache from the server code, but i don't yet know how to do that. 

@Larry
i) Do you think this is the way to go to solve this BZ? Having a cache that expires over time will update his permissions (rest api) once it times out
ii) I think we can have a cache expiration endpoint, that would be useful if the cache is 15 mins and the user don't want to wait for that.
iii) Should i look on how to programmatically create this cache for the rest auth?



[1] https://github.com/wildfly/wildfly/blob/639eb5f29fc15e92de992a250729a2f15ff2bc4b/security/src/main/java/org/jboss/as/security/plugins/DefaultAuthenticationCacheFactory.java#L39
[2] https://issues.jboss.org/browse/AS7-322?focusedCommentId=12601732&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12601732
[3] https://github.com/rhq-project/rhq/commit/5837457f16bdd16d7c956bfbeb549de0fe478e13

Comment 3 Josejulio Martínez 2018-08-17 17:44:28 UTC
Created a PR https://github.com/rhq-project/rhq/pull/348

Comment 4 Larry O'Leary 2018-08-20 21:05:37 UTC
I think this is the right approach. But we need to make sure that we can handle this in already installed environments automatically. Most likely by using apply-updates to add the new cache definition and configuration changes. This is handled via some jboss-cli batch command file.

In the PR I can see you still have 5837457f16bdd16d7c956bfbeb549de0fe478e13 reverted. Was this necessary? I only ask because I thought this was doing something different.

Comment 5 Josejulio Martínez 2018-08-20 21:24:52 UTC
5837457f16bdd16d7c956bfbeb549de0fe478e13 refresh the group to roles mapping of the user on every rest "login" (First request from the user or after the cache expired), that is still needed to ensure the groups the user belongs to are in sync.

This refresh covers when a role is added/removed from the group or when a group is added/removed to the (ldap) user.

My work ensures that those changes are kicked after some expiration time / force logout

Comment 6 Josejulio Martínez 2018-08-21 05:13:05 UTC
I did more testing, after step 7 of Comment 2

8)  Remove ldap group from "All Resources Role"
9)  Confirm that you can still see the platforms
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
10) Force a logout
  $ curl --user myTest:myTest http://localhost:7080/rest/user/logout
11)  Confirm that you do not see the platforms now
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
12) Add back the ldap group to "All Resources Role"
13) Force a logout
  $ curl --user myTest:myTest http://localhost:7080/rest/user/logout
14) Confirm that you can see the platforms again
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
15) Remove myTest from ldap jon-group
16) Confirm that you can see the platforms
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
17) Force a logout
  $ curl --user myTest:myTest http://localhost:7080/rest/user/logout
18) Confirm that you do not see the platforms now
  $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html

I still need to add the code to the apply-updates to ensure we fix existing environent

Comment 7 Larry O'Leary 2018-08-21 13:10:08 UTC
But what about 8), 9), and 11) without doing 10)? We want to make sure that this happens on its own after the cache expires. Are you confident that is working as expected? The forced logout should not be necessary. 

One could also argue that perhaps the logout action is not necessary. If a system administrator wanted to force the refresh of the auth cache, the recommendation would be a restart. However, I can see that perhaps the logout feature would be nice as it allows the refresh without interrupting other users.

Comment 8 Josejulio Martínez 2018-08-21 13:50:19 UTC
I set my cache expiration to 30 seconds and repeated the tests:

i)    Remove ldap group from "All Resources Role"
ii)   Confirm that you can still see the platforms
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
iii)  Wait expiration time 
iv)   Confirm that you do not see the platforms now
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
v)    Add back the ldap group to "All Resources Role"
vi)   Wait the expiration time
vii)  Confirm that you can see the platforms again
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
viii) Remove myTest from ldap jon-group
ix)   Wait expiration time
x)    Confirm that you do not see the platforms now
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html

Comment 9 Larry O'Leary 2018-08-21 14:08:13 UTC
Thanks Josejulio... One last test?

What happens for:

i)   Confirm that you do not see the platforms now
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html
ii)    Add back the ldap group to "All Resources Role"
iii)  Immediately confirm that you can see the platforms
   $ curl --user myTest:myTest http://localhost:7080/rest/resource/platforms.html



This is going to be the standard use-case. A system admin is going to add a new user's ldap group to a role and map it to a resource group. The user is then going to attempt the login. I am assuming because the token won't be in the cache, a normal auth/authz lookup will occur and if successful, be added back to the cache?

Comment 10 Josejulio Martínez 2018-08-21 14:31:10 UTC
Actually, i) will put the user in the cache, so when doing step (iii) won't see the platforms until the cache expires or the user logs out.

Comment 12 Josejulio Martínez 2018-09-05 18:54:34 UTC
commit 7d192190cf11aafbe3e3ba8b2bea55aab3d4bf03 (origin/bugs/1542125, bugs/1542125)
Author: Josejulio Martínez <jmartine>
Date:   Fri Aug 17 12:18:57 2018 -0500

    Bug 1542125 - Allows rest user to logout to be able to refresh its permissions
     - Set SecurityDomain[RHQRESTSecurityDomain] cache-type to infinispan
     - Creates infinispan cache at server install
       (named security, which is what cache-type=infinispan uses)
     - Creates new endpoint /user/logout to force the removal of the
       logged user cache

Comment 13 Josejulio Martínez 2018-09-06 17:15:07 UTC
This commit is also needed:

commit ffcd2e09291d6b4f748d12896ebcecf6ab1aff90
Author: Josejulio Martínez <jmartine>
Date:   Fri Aug 17 09:48:05 2018 -0500

    Revert " [BZ 1380706] JBoss ON user's roles do not always match for LDAP mapping for CLI logins."
    
    This reverts commit 5837457f16bdd16d7c956bfbeb549de0fe478e13.

Comment 18 Josejulio Martínez 2018-09-20 22:57:05 UTC
commit 176395b0e7d1e98b51b34d25f46290fec22d5af4 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Merge: 8146a892f9 ef7aec34cd
Author:     Josejulio Martínez <finwemartinez>
AuthorDate: Thu Sep 20 17:55:38 2018 -0500
Commit:     GitHub <noreply>
CommitDate: Thu Sep 20 17:55:38 2018 -0500

    Merge pull request #351 from josejulio/bugs/1542125-2
    
    Bug 1542125 - Allow the server to start even if we don't have the req…

Comment 19 Josejulio Martínez 2018-09-20 22:57:57 UTC
commit ef7aec34cd60111c7f65f5ac458f2598fd099281 (origin/bugs/1542125-2, bugs/1542125-2)
Author:     Josejulio Martínez <jmartine>
AuthorDate: Thu Sep 20 17:46:31 2018 -0500
Commit:     Josejulio Martínez <jmartine>
CommitDate: Thu Sep 20 17:46:31 2018 -0500

    Bug 1542125 - Allow the server to start even if we don't have the required cache-container for the rest logout
     This allows the updater to start the server to properly configure it.

Comment 20 Josejulio Martínez 2018-09-24 15:07:53 UTC
commit 79eaa079037f61176e95b63f2858c10c6939fdb3 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Author:     Josejulio Martínez <finwemartinez>
AuthorDate: Mon Sep 24 04:43:29 2018 -0500
Commit:     Michael Burman <yak>
CommitDate: Mon Sep 24 12:43:29 2018 +0300

    Bug 1542125 - Ensure we always close the context (#352)

Comment 25 errata-xmlrpc 2018-10-16 17:06:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2930