[keycloak-dev] Allow to search for users by exact attribute match.
Thomas Darimont
thomas.darimont at googlemail.com
Tue Jan 19 14:48:29 EST 2016
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.
>
>> 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
>
>> 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/7f606c5b/attachment-0001.html
More information about the keycloak-dev
mailing list