+++ This bug was initially created as a clone of Bug #1192831 +++

Description of problem:
I have a repository with access restricted to certain roles. A user, who has none of these roles, has no access to this repository. However, the user can search for assets including assets in this repository and then can view them and even modify them.

Version-Release number of selected component (if applicable):
JBoss BRMS 6.0.3 (but the same problem applies also to Drools 6.2)

How reproducible:
See steps below.

Steps to Reproduce:
1. Use kie-config-cli to create repository repository1 and grant access to this repository to role role1. Use list-repo command to verify, that the setup is as follows:

list-repo
Result:
Currently available repositories:
Repository repository1
scheme: git
uri: git://repository1
environment:

roles: [role1]

2. Create user analyst (e.g. using add-user script in JBoss EAP) and grant him role analyst.
3. Log in to business central as some administrator and create a project with some assets in the repository1 repository.
4. Log out from business central and log in as analyst.
5. When you click Authoring -> Project authoring, the user cannot access the repository1 repository. This is OK.
6. Now click Find and in the search form specify some date in the past as Last modified after.
7. Click Search.
8. All the assets of the repository1 repository are shown, you can view them and modify them. This is incorrect, because the user analyst should have no access to the repository1 repository.

Actual results:
User can access assets in a repository, which he has no privileges for.

Expected results:
Access to the assets in that repository should be denied.

Additional info:
The same problem applies to the latest version of Drools (i.e. Drools 6.2) as well.

— Additional comment from JBoss Product and Program Management on 2015-02-15 13:10:17 EST —

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

— Additional comment from Kris Verlaenen on 2015-02-16 09:59:56 EST —

Michael, not sure if improving search to exclude certain assets could still be done as a localized, quick fix for 6.1?

— Additional comment from on 2015-02-16 10:13:24 EST —

(In reply to Kris Verlaenen from comment #2)
> Michael, not sure if improving search to exclude certain assets could still
> be done as a localized, quick fix for 6.1?

The problem is it's not just "Search" that is affected. For example IIRC Designer retrieves a list of "Ruleflow Groups" for use in process authoring. Should this now be restricted to "Ruleflow Groups" for rules to which the User has access? The same, general question, can be asked of anywhere we allow querying of the indexed meta data.

— Additional comment from Kris Verlaenen on 2015-02-17 11:34:43 EST —

Agreed, this type of UI filtering by assigning roles to repos should ideally be applied everywhere. However, the impact of search seems to be much more severe, as it allows users to view and even modify the assets, the usage of the indexed data in other locations seems much less severe.

— Additional comment from on 2015-02-18 05:31:12 EST —

uberfire-extensions
-------------------
(master) https://github.com/uberfire/uberfire-extensions/commit/4a7b47d1c

(0.5.x) https://github.com/uberfire/uberfire-extensions/commit/e93473598

kie-wb-common
-------------
(master) http://github.com/droolsjbpm/kie-wb-common/commit/4cb054f1b

(6.2.x) http://github.com/droolsjbpm/kie-wb-common/commit/3cafd6187

— Additional comment from on 2015-02-18 05:31:56 EST —

Filtered Search Results by Repository(ies) to which the User has access.

— Additional comment from Pavel Zeman on 2015-02-19 15:49:41 EST —

Just to be sure - It was not explicitly mentioned in the bug, but the same problem applies also to organizational units. Are the search results filtered also by the organizational units, to which the user has access?

— Additional comment from Ryan Zhang on 2015-03-04 06:25:10 EST —

Please set + for the flag 6.1.0 since this issue is fixed for 6.2.x branch.
It should be present in 6.1.0 ER6 release.

— Additional comment from Radovan Synek on 2015-03-19 09:27:14 EDT —

Tested with BRMS-6.1.0.ER6, unfortunately the fix does not help, see the attached screenshot - although the user cannot see the repository in Project Explorer, still is able to access some assets via search.

— Additional comment from Radovan Synek on 2015-03-19 09:28:22 EDT —

— Additional comment from on 2015-03-20 06:38:57 EDT —

There appears to have been a regression introduced in the underlying (Uberfire) security mechanisms; see the referenced BZs. I will re-test this locally before setting to (I hope) MODIFIED when these BZs are resolved.

— Additional comment from on 2015-03-23 10:41:23 EDT —

I confirmed this is now working with the fixes made for the captioned BZs.

— Additional comment from Tomas David on 2015-10-07 10:55:27 EDT —

Tested on BRMS 6.2.0.ER3.

Issue is still present in business central.

— Additional comment from on 2015-10-19 05:45:15 EDT —

I tested with jboss-brms-6.2.0.ER4-deployable-eap6.x and it works fine!

One thing that may be the cause of our discrepancies, is that after a role has been added to either an OU or Repository with kie-cli-config is that the Application Server needs stopping and re-starting. This is an issue and one best recorded against https://bugzilla.redhat.com/show_bug.cgi?id=1214245.

This is what I did:-

1) Run Business Central
2) Login with a User that has the admin role
3) Create repositories Repo1 and Repo2
4) Create projects Project1 in Repo1 and Project2 in Repo2
5) Create DRL files in Project1 and Project2
6) Run kie-cli-config.sh
7) Add role1 to Repo1 and role2 to Repo2
8) Make sure to execute command push-changes
9) Run add-user.sh
10) Create User1 with role role1 and User2 with role2
11) *STOP EAP*
12) *RESTART EAP*
13) Login with User1, they can only see Repo1 in Project Explorer
14) Search for assets, only that in Repo1 is listed
15) Login with User2, they can only see Repo2 in Project Explorer
16) Search for assets, only that in Repo2 is listed

— Additional comment from on 2015-10-19 05:52:35 EDT —

(In reply to Pavel Zeman from comment #7)
> Just to be sure - It was not explicitly mentioned in the bug, but the same
> problem applies also to organizational units. Are the search results
> filtered also by the organizational units, to which the user has access?

I tested when an OU has a security role, but the inner Repository does not and this remains an issue as User1 could "see" (and open) assets in the repository in the OU to which the user does not have permissions.

— Additional comment from Tomas David on 2015-10-19 07:13:12 EDT —

Hello Michael,

it also works for me if I restart eap server and you have right, issue is still present for org units.

— Additional comment from on 2015-10-20 05:33:57 EDT —

kie-wb-common
-------------
(master) https://github.com/droolsjbpm/kie-wb-common/pull/115

Will submit PR for 6.3.x when the above is merged.

— Additional comment from Toni Rikkola on 2015-10-21 02:35:50 EDT —

Merged

kie-wb-common
-------------
(master) https://github.com/droolsjbpm/kie-wb-common/commit/c00e1caed

— Additional comment from on 2015-10-21 04:43:28 EDT —

kie-wb-common
-------------
(6.3.x) https://github.com/droolsjbpm/kie-wb-common/pull/119

Will set to MODIFIED when this PR is merged.

— Additional comment from on 2015-10-21 05:39:51 EDT —

Merged

kie-wb-common
-------------
(6.3.x) http://github.com/droolsjbpm/kie-wb-common/commit/e6769e21b

— Additional comment from Pavel Kralik on 2015-11-06 07:01:41 EST —

I tested with BPMS 6.2.0.ER5 and if I restricted OU or repository access to some role. Analyst can stil search both and modify all files.

— Additional comment from on 2015-11-09 10:55:42 EST —

Hi,

I am still investigating, but it appears the first change to system.git using kie-cli-config is "lost" and doesn't trigger updates to the cached information relating to roles for OUs and Repositories.

I can replicate the issue, but also work-around, by adding 1 role, push-changes and then another role and push-changes. Access permissions are correct following the second commit.

I'll keep you updated.

With kind regards,

Mike

— Additional comment from on 2015-11-10 08:53:11 EST —

uberfire
--------
(master) https://github.com/uberfire/uberfire/pull/215

— Additional comment from on 2015-11-10 12:10:06 EST —

uberfire
--------
(0.7.x) https://github.com/uberfire/uberfire/pull/216

— Additional comment from on 2015-11-11 08:00:14 EST —

uberfire
--------
(master) https://github.com/uberfire/uberfire/commit/08c927736

(0.7.x) https://github.com/uberfire/uberfire/commit/3c0278aeb

— Additional comment from Pavel Kralik on 2015-11-20 10:42:35 EST —

Created two DRL's on fresh installed BPMS 6.2.0.CR1 - drl1, drl2 as admin. Then used kie-config-cli with add-group-repo for repository1 to admin. Relogged to BC as analyst and searched both drl's ans changed them. Repository1 was disabled. When openned drl as admin it was changed.

— Additional comment from on 2015-11-23 11:37:59 EST —

kie-wb-distributions
--------------------
(6.3.x) https://github.com/droolsjbpm/kie-wb-distributions/pull/146

— Additional comment from on 2015-11-23 11:42:38 EST —

kie-wb-distributions
--------------------
(master) https://github.com/droolsjbpm/kie-wb-distributions/pull/147

— Additional comment from on 2015-11-24 11:03:21 EST —

kie-wb-distributions
--------------------
(master) https://github.com/droolsjbpm/kie-wb-distributions/commit/a2ab48e69

(6.3.x) https://github.com/droolsjbpm/kie-wb-distributions/commit/145f992e6

— Additional comment from Pavel Kralik on 2015-12-03 08:03:51 EST —

Created two DRL's on fresh installed BPMS 6.2.0.CR2/EAP6.4 - drl1, drl2 as admin.
Used kie-config-cli.sh and add-group-repo to add repository1 to admin.
Logged in to BC as analyst and hit search and find both drl's changed them and saved. repository1 was disabled.
When reopened DRL's as admin both were changed.

— Additional comment from Pavel Kralik on 2015-12-03 08:18:16 EST —

I have done a restart of the BPMS/EAP and still the same situation for repository/OU.

— Additional comment from on 2015-12-03 08:19:28 EST —

I tried with a complete fresh install of BRMS from here: http://dev138.mw.lab.eng.bos.redhat.com/candidate/brms-6.2.0.CR2/ copied your steps and could not replicate. Works as expected.

Trying BPMS from http://dev138.mw.lab.eng.bos.redhat.com/candidate/bpmsuite-6.2.0.CR2/ too now..

— Additional comment from on 2015-12-03 08:25:57 EST —

Completed the same test with BPMS (from http://dev138.mw.lab.eng.bos.redhat.com/candidate/bpmsuite-6.2.0.CR2/) and cannot replicate the issue either.

— Additional comment from on 2015-12-03 08:31:22 EST —

These are the steps I am following:-

1) Create new folder (to install Business Central)
2) cd into new folder
3) Unzip EAP
4) Unzip BxMS
5) Move BxMS files into EAP folder
6) ./standalone.sh
7) ./add-user.sh
8) Create user1, role admin
9) Create user2, role analyst
10) Login to Business Central as user1
11) Go to Administration Perspective
12) Create new Repository (r1)
13) Create new Repository (r2)
14) Go to Authoring Perspective
15) Create new Project (r1proj) in r1
16) Create new Project (r2proj) in r2
17) Create new DRL file (r1proj-drl) in r1proj; selecting "non-default" package
18) Create new DRL file (r2proj-drl) in r2proj; selecting "non-default" package
19) Search for "drl". r1proj-drl and r2proj-drl are returned
20) Logout

21) Run kie-cli-config.sh
22) Login as user1
23) add-group-repo; adding admin to r1
24) push-changes
25) exit

26) Login to Business Central as user1
27) Search for "drl". r1proj-drl and r2proj-drl are returned
28) Logout

29) Login to Business Central as user2
30) Search for "drl". Only r2proj-drl is returned.

— Additional comment from on 2015-12-03 08:35:20 EST —

Please detail the exact steps you are using that replicate the issue.

— Additional comment from Pavel Kralik on 2015-12-03 10:45:55 EST —

I tried https://bugzilla.redhat.com/show_bug.cgi?id=1192831#c34 and it worked for me.

Reproducer:

1) Create new folder (to install Business Central)
2) cd into new folder
3) Unzip EAP
4) Unzip BxMS
5) Move BxMS files into EAP folder
6) ./standalone.sh
7) bin/add-user.sh -a -u 'user1' -p 'user123*' -ro 'admin'
8) bin/add-user.sh -a -u 'user2' -p 'user234*' -ro 'analyst'
9) Login to Business Central as user1
10) Go to Authoring Perspective
11) Select default: example / repository1 / project1
12) Create 5 DRL's with names drl1, drl2, drl3, drl4, drl5 each with various package: <default>, org, org.kie, org.kie.example, org.kie.example.project1
13) Search for "drl". drl1, drl2, drl3, drl4, drl5 are returned.
14) Login to Business Central as user2
15) Search for "drl". drl1, drl2, drl3, drl4, drl5 are returned.
16) Run kie-cli-config.sh
17) Login as user1
18) add-group-repo; adding admin to repository1
19) push-changes
20) exit
21) Login to Business Central as user2
22) Search for "drl". drl1, drl2, drl3, drl4, drl5 are returned.

— Additional comment from Tomas David on 2015-12-03 11:12 EST —

Hello Michael,

I found similar problem that might be related to this issue:

1) Follow your first 9 steps
2) Go to administration perspective
3) Clone for example quickstarts repository https://github.com/jboss-developer/jboss-brms-repository.git into example org unit. (as user1)
4) Login as user2
5) Open quickstarts repo - bpms-project. Do not close browser window.
6) Run kie-cli-config.sh
7) Login as user1
8) add-group-repo (quickstart to admin role)
9) push-changes
10) exit
11) Logout user2 from browser.
12) Login as user2 in browser.
13) Go to Authoring Perspective.
14) Files of bpms project are visible and editable.

See the attached screenshot.

— Additional comment from on 2015-12-03 14:31:51 EST —

@pkralik

Great, thanks. This is caused by there being zero repositories to which the user has access (yikes!). By simply adding a new Repository (as user1); user2 can no longer see any of the DRL files. Basically the issue is when we construct the "search criteria" we only append criteria restricting which Repositories to scan if there are more than zero authorized repositories. In my steps this becomes "query=drl+repo=repo1" but when there are zero authorized repositories it becomes "query=drl" so all matches in all repositories are returned. Working on a fix...

@tdavid,

I'll try your scenario after I've fixed the above..

— Additional comment from on 2015-12-04 05:04:20 EST —

uberfire-extensions
-------------------
(master) https://github.com/uberfire/uberfire-extensions/pull/142

(0.7.x) https://github.com/uberfire/uberfire-extensions/pull/144

— Additional comment from on 2015-12-04 05:24:06 EST —

@Pavel,

Final(Unable to render embedded object: File (?) fix pending merge into codebase. Yay) not found.

@Tomas,

I followed your steps but was not able to reproduce.

In step #14 do you mean the "quickstart" Repository is listed in Project Explorer for user2 and they can navigate the content; or do you mean if you search for "drl" you get files listed in the "quickstart" repository?

Tomas, you also don't state what version you are using (there have been a lot of wrinkles fixed relating to authorization and use of kie-cli-config against this BZ.. please be sure to use 6.2.0.CR2/GA).

My results (following your steps) were that the "quickstart" Repository was removed from Project Explorer for user2 and searching for "drl" did not return any assets in "quickstart".

— Additional comment from on 2015-12-04 05:51:17 EST —

@Lukas, this BZ still has the blocker+ flag set for 6.2.0. Can you please advise whether the latest fix is to be merged into the 6.3.x (community) branch now or whether we're to wait for the 1-6.2.x rollup? I'll need to stop it being merged if this is the case!

— Additional comment from Lukáš Petrovický on 2015-12-04 05:54:08 EST —

(In reply to manstis from comment #41)
> @Lukas, this BZ still has the blocker+ flag set for 6.2.0. Can you please
> advise whether the latest fix is to be merged into the 6.3.x (community)
> branch now or whether we're to wait for the 1-6.2.x rollup? I'll need to
> stop it being merged if this is the case!

For the time being, let's not merge it - I am not expecting any more 6.2.0 builds. At this point, I'm assuming that the blocker flag for this (and 1 other ASSIGNED blocker+ bug) will be reset later today.