[keycloak-dev] Allow to search for users by exact attribute match.
Thomas Darimont
thomas.darimont at googlemail.com
Tue Jan 19 15:06:50 EST 2016
2016-01-19 20:54 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>
> On 19 January 2016 at 20:48, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Answers inline
>>
>> 2016-01-19 19:52 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> We've decided to leave the admin endpoints as is for 1.x series. In 2.x
>>> series we'll introduce a version 2 of the API which won't be backwards
>>> compatible. This will give us greater flexibility in improving the API, but
>>> still support the older API for some time.
>>>
>>>
>> Sounds reasonable - will keep that in mind!
>>
>>
>>> On 19 January 2016 at 12:20, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> I just wanted to ensure backwards compatibility - an additional
>>>> parameter would break (java) API
>>>> consumers who are currently using the keycloak-admin-client, since they
>>>> are potentially using the
>>>> variant without the parameter.
>>>> This would of course be no problem for REST API consumers.
>>>>
>>>> What I see as a problem though is the behaviour change of the search
>>>> behaviour by default ...
>>>> (knowing the current API) I'd rather expect that the search would
>>>> perform the same as before
>>>> with fuzzy matching /by default/ and support for exact match if
>>>> explicitly stated.
>>>>
>>>> However having a search operation that performs an exact search by
>>>> default "feels" more natural to me - so I'm fine with your suggestion
>>>> as a quick solution :)
>>>>
>>>
>>>> Regarding urls:
>>>> I'd rather prefer to have some dedicated search sub-resources per
>>>> entity - but that is a more general topic...
>>>> With this approach one would be more flexible with respect to supported
>>>> searches
>>>> that could behave completly different.
>>>>
>>>> Entity lookups by id
>>>> /entity/{id}
>>>>
>>>> Dedicated lookup sub-resource for other attribute lookups: (here I'd
>>>> expect exactly 0 or 1 results)
>>>> /entity/lookup/byName?name=someName
>>>> /entity/lookup/byEmail?email=someEmail
>>>>
>>>> Dedicated search sub-resources: (here I'd expect 0 or n results)
>>>>
>>>> /entity/search/byName?name=someName
>>>> /entity/search/byNameMatching?pattern=someName
>>>> /entity/search/byAttributes?firstname=firstname&lastname=lastname
>>>>
>>>
>>> -1 A single resource with different query params is much cleaner IMO
>>>
>>>
>> Yes and no, it may look cleaner to some degree in the beginning but once
>> more sophisticated
>> user searches / lookups become necessary it can turn into a mess because
>> one has to deal
>> with a bunch of different parameters and handle the resulting parameter
>> combinations in a proper way.
>> Having dedicated search endpoints makes it easier to provide narrowly
>> focused search APIs IMHO.
>>
>
> It always depends. I can't see us providing so many different search
> endpoints that having multiple different endpoints will be cleaner. Having
> one endpoint with multiple params also provides more flexibility. For even
> more flexibility you can use something along what Mongo does to include a
> complex json object for the search params.
>
>
Yes, generally I agree - but I'm a bit biased since I come from a Spring
Data Rest background:
http://docs.spring.io/spring-data/rest/docs/current/reference/html/#repository-resources.search-resource
having dedicated resources makes it IMHO easier to build self-describing
discoverable hypermedia REST endpoints
since it is easier to represent sub resources via dedicated rels then
refering to a subset or permutation of query parameters.
>>
>>>
>>>> In addition to that one could also allow @POST requests to these
>>>> (sub-)resources
>>>> where the actual parameters are extracted from form-parameters in order
>>>> to avoid leaking user information like username, email, etc. in access
>>>> logs.
>>>> I think this would be relevant for an application that deals with
>>>> security sensitive information
>>>> like keycloak does.
>>>>
>>>
>>> Agree with the security sensitivity, but it sounds very non-rest
>>>
>>>
>> Yes indeed, that's one occasion where one has to deviate from traditional
>> rest teachings for the sake of security ;-)
>> Although using POST requests don't make the whole app more secure but
>> helps, as said to not leave unnecessary
>> traces in proxy / access logs etc.
>>
>> http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other
>>
>
> Assuming HTTPS is used then the only place that query params could be
> leaked is in the web server log, so wouldn't it be more sensible to make
> sure they are not included in the server logs?
>
>
Yes that's right one has many options here - using POST requests are an
easy way to do so.
>
>>
>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>
>>>> 2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>
>>>>> -1 To additional search method. URL should be '.../users'.
>>>>>
>>>>> Simplest is just to change what we have now to not included wildcards.
>>>>> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
>>>>> Default should be false. Alternatives are:
>>>>>
>>>>> * Let users add % themselves
>>>>> * Add separate query params for fuzzy
>>>>>
>>>>> On 19 January 2016 at 10:27, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track
>>>>>> this.
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>>>>>> thomas.darimont at googlemail.com>:
>>>>>>
>>>>>>> Okay, how about offering a new search method that accepts s
>>>>>>> UserSearch DTO that would hold the attributes to search by
>>>>>>> as well as a "match mode". Could also be used to specify pagination.
>>>>>>>
>>>>>>> This could also be send via a @POST in order to avoid retaining
>>>>>>> userdata like usernames, email addresses etc. in
>>>>>>> access logs...
>>>>>>>
>>>>>>> Alternatively you could introduce a searchExact(..) method with the
>>>>>>> same parameterization as the existing search method.
>>>>>>>
>>>>>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>>>
>>>>>>>> It was by design, but it wasn't a good design. Would be better to
>>>>>>>> make it match exact, but allow including a wildcard to make it fuzzy.
>>>>>>>>
>>>>>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was looking for a way to query users based on their exact
>>>>>>>>> username but it turned out, that
>>>>>>>>> org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>>>>>> String, String, String, Integer, Integer)
>>>>>>>>>
>>>>>>>>> @GET
>>>>>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>>>>>> List<UserRepresentation> search(@QueryParam("username") String
>>>>>>>>> username,
>>>>>>>>> @QueryParam("firstName")
>>>>>>>>> String firstName,
>>>>>>>>> @QueryParam("lastName")
>>>>>>>>> String lastName,
>>>>>>>>> @QueryParam("email") String
>>>>>>>>> email,
>>>>>>>>> @QueryParam("first")
>>>>>>>>> Integer firstResult,
>>>>>>>>> @QueryParam("max") Integer
>>>>>>>>> maxResults);
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>> usersResource.search("exactusername",null,null, null, null,
>>>>>>>>> email, 0, 10)
>>>>>>>>>
>>>>>>>>> generates a like %..% query in
>>>>>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>>>>>
>>>>>>>>> Since usernames are unique per realm I think it would make sense
>>>>>>>>> to be able to perform a
>>>>>>>>> query for the exact username (or perhaps the combination of other
>>>>>>>>> attributes as well).
>>>>>>>>>
>>>>>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/3a6d7b79/attachment-0001.html
More information about the keycloak-dev
mailing list