Skip to content
This repository has been archived by the owner on Jul 3, 2020. It is now read-only.

Bulk searchUsers operation #143

Open
timopick opened this issue Jun 15, 2015 · 4 comments
Open

Bulk searchUsers operation #143

timopick opened this issue Jun 15, 2015 · 4 comments
Labels

Comments

@timopick
Copy link

From @umerkayani:
In Vibesa we require a more efficient version of searchUsers method of connector4java component. Right now we have the method as follows:

public SCIMSearchResult<User> searchUsers(Query query, AccessToken accessToken)

and we need something like this:

public List<SCIMSearchResult<User>> searchUsers(List<Query> queries, AccessToken accessToken)
@tkrille
Copy link
Member

tkrille commented Jun 15, 2015

Why not simply make multiple calls yourself, or create a viable abstraction around the connector, or do you want to send multiple queries at once to the resource-server and get back multiple SCIMSearchResults at once, too?

@tkrille
Copy link
Member

tkrille commented Jun 15, 2015

The last option is covered by the SCIM api spec: http://tools.ietf.org/html/draft-ietf-scim-api-19#section-3.7

So this has to be supported in the resource-server, too.

@timopick
Copy link
Author

Exactly. The scenario is as follows: There is an authorization component within vibesa that defines and evaluates the user permissions.

Example: If the following search query returns the current user, the permission is granted.

Permission [id=9, name=Zielgruppe Antrag: Einkommenserklärung (SF/FH, JONA),
    description=Einkommenserklärung (SF/FH, JONA),
    rule=(groups.display eq "vr_stipendiat" OR groups.display eq "vr_anwaerterStipendiat")
        AND (urn:scim:schemas:vibesa:1.0:vibesa.stipfoetyp eq "SF"
            OR urn:scim:schemas:vibesa:1.0:vibesa.stipfoetyp eq "FH"
            OR urn:scim:schemas:vibesa:1.0:vibesa.stipfoetyp eq "JONA")]

The rule part of each permission is an OSIAM searchUsers query. We have roundabout 50 permissions, that need to be checked for each user who tries to access the application. This means 50 searchUsers requests per user. This creates a lot of round-trip-time. In order to eliminate the server roundtrips, Vibesa team would welcome a bulk request with all the 50 queries and a response list that contains responses for all the queries.

@tkrille
Copy link
Member

tkrille commented Jun 16, 2015

Searching is the most costly operation you can do with OSIAM, especially when it comes down to extensions and the OR operator. For each search request, most of the time will be spent in the resource-server and database, collecting and transforming the results. So by bulking the requests you definitely gain a little performance boost, but a bulk search with 50 queries can easily take multiple seconds to complete. Do you make these searches on every request of a user or just initially when they login? Nevertheless, I would suggest that you fetch and cache the complete User object and check the rules in-memory in your app. Maybe put the User in the session or something.

Having said that, implementing bulk operations, as defined by the SCIM 2.0 specs, is something that's really useful for OSIAM. And we'll love to implement that. We could start with search and get, and schedule the mutating methods for the future. As this must be implemented in the resource-server, someone should open an issue there, too. For the next time, please use the general, overarching issue tracker here: https://github.com/osiam/osiam/issues

@dacrome dacrome mentioned this issue Oct 12, 2015
48 tasks
@tkrille tkrille added this to the 2.0 milestone Oct 17, 2015
@tkrille tkrille removed this from the v2.0 milestone Nov 2, 2015
tkrille added a commit to tkrille/osiam-connector4java that referenced this issue Feb 5, 2016
…Result

Introduce Constant representing ListResponse
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants