This should improve the processing of filters for appRoleAssignments
a bit when combining them with other filters. We try to avoid reading
the full user list if possible. And delay the processing of an
appRoleAssignments filter so we can apply it on a subset of user.
E.g. a filter:
`appRoleAssignments/any(m:m/appRoleId eq 71881883-1768-46bd-a24d-a356a2afdf7f) and memberOf/any(m:m/id eq 509a9dcd-bb37-4f4f-a01a-19dca27d9cfa)`
Will be reordered to first process the memberOf filter (which can be
executed without reading the full user list) and only apply the
appRoleAssignments filter on the resultset of the memberOf filter.
This add support for filtering on the `appRoleAssignment` relation of
users. E.g.
```
$filter=appRoleAssignments/any(m:m/appRoleId eq '262982c1-2362-4afa-bfdf-8cbfef64a06e')
```
combining it with a filter on groupMemberShip does also work:
```
$filter=memberOf/any(m:m/id eq '262982c1-2362-4afa-bfdf-8cbfef64a06e') and appRoleAssignments/any(m:m/appRoleId eq 'd7beeea8-8ff4-406b-8fb6-ab2dd81e6b11')
```
The filter is still very inefficient as it always needs to get the full
users list. We need to adapt it to only filter on a subset of users when
using this filter 'and' combined with other filters.
Closes: #5488
With 078698fdf4 the semantics of the
ListRoleAssignments Call in the settings service change. It no
no longer returns a "not found" error when there is not RoleAssignment
for a user. We'll just get an empty list as the result.
This changes the behaviour of the default role assignment to work with
the new semantics.
When refint is enabled on an LDAP server, it will rename all references
to an entity if its DN is modified. If this happens, the member
renames will not be needed, and will also return an error.
This PR does the following:
* Detects the attribute error, and don't return an error.
* Log that the server has been misconfigured.
* Add config value that skips renaming if set.
* Add http endpoint to list permissions
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* extract handler registration
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* use generated protobuf
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* update permissions mock in graph service
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* add unit test
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* return correct userid
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
* assert error message type in tests
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
---------
Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>
This is an incomplete implementation of username changing code.
The things still needed to be finished:
* The method that changes the member attribute has to be filled in.
* The functionality needs to be tested.
* Unit tests need to be added.
This adds some initial support for using $filter (as defined in the
odata spec) on the /users endpoint. Currently the following filters are
supported:
A single filter on `id` property of the `memberOf` relation of users.
To list all users that are members of a specific group:
```
curl 'https://localhost:9200/graph/v1.0/users?$filter=memberOf/any(m:m/id eq '262982c1-2362-4afa-bfdf-8cbfef64a06e')
```
A logical AND filteri on the `id` property of the `memberOf` relation of users.
`$filter=memberOf/any(m:m/id eq 262982c1-2362-4afa-bfdf-8cbfef64a06e) and memberOf/any(m:m/id eq 6040aa17-9c64-4fef-9bd0-77234d71bad0)`
This will cause at least two queries on the identity backend. The `and`
operation is performed locally.
Closes: #5487
