Repository navigation
Advanced query language to search for users - #15998
nicolasiannarilli wants to merge 1 commit into
Conversation
4df6073 to
6b4ca89
Compare
|
In general, I think having a more flexible queries might be nice. However, aren't there standard languages for these kinds of queries? |
|
Except for LDAP-like queries I'm not aware of any language like that, are you thinking of something in particular? Our implementation in JSON is quite flexible and extensible if needeed. |
|
Just saying, there do exist many query languages, like on https://github.com/AnanthaRajuC/List-of-programming-language-lists/blob/master/language-files/Query%20language.md – and this list is only the tip of the iceberg. |
|
Thanks for your interest in this PR. Although I believe the JSON expression proposed is not a really a language, but just a data structure representing the search criteria, I also recognize that a concise way of expressing the search criteria can be useful. I understand that developping a custom language from scratch is not good idea, but with complex query language, adding a new dependency to the keycloak project may cause maintenance issues. By using a JSON structure, we can benefit from the Jackson library. Because it is widespread, this format is quite easy to read and understand for any tech user, whereas a new language need learning. I looked around for a query language that could fit and found "RSQL/FIQL", which seems to be a good candidate. There's already a java library to parse this language (https://github.com/jirutka/rsql-parser) (but it seems to not be maintained anymore). What do you suggest, should we add a new language or go along with the PR as it is ? |
|
What you linked has not been touched in the last 7 years, so it is probably not the best option. Personally, I would have looked at GraphQL. However, this would more or less mean adding a whole new API. |
|
You're right, I think it'd be best avoiding unmaintained solutions. Supporting GraphQL would require a major overhaul of the KC API, which is far exceeding the scope of this PR. That's why I still think the proposed JSON structure is a good compromise. I could maybe refactor my code to implement a visitor pattern and allow future implementations of a query language. |
|
Independently of what the solution should be in the end, I'd very much welcome a way to do some advanced queries in Keycloak. |
6b4ca89 to
c690dae
Compare
|
@dalbani You can use multiple requests as a workaround. I agree it's not ideal and I would appreciate better querying capabilities. @nicolasiannarilli I am not sure it makes sense to continue working on this without feedback from the maintainers. |
|
I think the right thing to do here would be to add support for SCIM https://bookstack.soffid.com/books/scim/page/scim-query-syntax |
|
Closing this as it is not something we'll consider for the current Admin APIs. We should consider some form of advanced queries as part of Admin v2 APIs, see https://github.com/keycloak/keycloak/discussions/categories/api-guidelines to join discussions around that. We also do have plans on adding SCIM, which should also support SCIM query syntax. |
Feature summary
This enhancement would add a new way to create queries for searching users. Using a JSON description of the search criteria, one would be able to craft complex queries like:
{ "operator": "and", "values": [ { "operator": "equals", "property": "username", "value": "sjohn" }, { "operator": "like", "property": "firstName", "value": "*jo*" } ] }See #14478 for more information.