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: | Security | Assignee: | 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.10 | CC: | jmartine, loleary, spinder |
Target Milestone: | CR01 | Keywords: | 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
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 Created a PR https://github.com/rhq-project/rhq/pull/348 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. 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 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 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. 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 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? 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. 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 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. 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… 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. 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) 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 |