KeyCloak: Estudi d'obtencio d'usuaris a partir de per part de DNI, part de username o part de nom-llinatge.

Bones:

El meu estudi s'ha centrat en tenir alguna cosa similar a la cerca de persones a PortaFIBi Carpeta més les demandes de Limit en la cerca d'usuaris.

Requeriments PortaFIB:

Cerca per username complet
Cerca per NIF complet
Tenir mètode per comptar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom-llinatges, email o NIF.
Tenir mètode per recuperar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom-llinatges, email o NIF.

Requeriments Carpeta:

Cerca per username complet
Cerca per NIF complet

Requeriments Limit:
Tenir mètode per recuperar usuaris que s'ajusten al filtre parcial sobre el camp nom-llinatges.

Per optimitzar les consultes amb filtres parcials hi ha dues possibles solucions:

(S.1) Que els mètodes incloguin paràmetres per indicar el numero màxim d'entrades. Aquest sistema funciona només en el cas que la primera petició retorni valors amb un total d'entrades menor al numero màxim d'entrades demanades. En cas contrari no es poden mostrar els valors recuperats ja que sabem que n'hi ha més i s'ha d'esperar a que l'usuari ajusti el filtre.

(S.2) Afegir mètodes que donat un filtre comptin el numero de instancies d'usuari que s'ajustin. Aquest sistema sempre requereix la consulta de count() que és molt eficient i un cop el valor retornat per count s'ajusti al numero màxim d'entrades demanades, és quan s'ha de fer una consulta de recuperació de llistat d'usuaris. -AVANTATGES: No degrada el rendiment ja que l'accés a la "BBDD" de KeyCloak només demana el count i tampoc no perd temps processant resultats. Millora la comunicació ja que enlloc de retornar un conjunt d'entrades d'usuari Rest, només retorna un sencer. -INCONVENIENTS: Fins i tot quan el filtre està acotat numero màxim d'entrades demanades, sempre s'han de fer dues cridades count()+recuperacióDeDades()

A causa de la gran quantitat de resultats que hi pot haver en Producció i prevenint futurs problemes de rendiment, elegiré l'opció S.2.

A partir d'aquí l'API de Plugin UserInformation s'haurien de implementar els següents mètodes:

Mètode per comptar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom, llinatges, email o NIF.
Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom, llinatges, email o NIF.
Mètode per comptar usuaris que s'ajusten al filtre parcial sobre el camp nom-llinatges.
Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre el camp nom-llinatges.
Mètode per comptar usuaris que s'ajusten al filtre parcial sobre el camp username.
Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre el camp username.
Altres mètodes de comptar/recuperar per email o nif.

Farem l'estudi dels Nous mètode a partir de la Implementació per KeyCloak (Plugin de UserInformation de KeyCloak)

(K.1) Mètode per comptar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom, llinatges, email o NIF.

Actualment no existeixen mètodes per comptar a la versió de KeyCloak 8.0.1.
Es podria fer un afegit al servidor per ampliar els serveis Rest disponibles tal i com descriu aquest article: https://dev.to/silentrobi/keycloak-custom-rest-api-search-by-user-attribute-keycloak-3a8c (SI PROVAT). S'ha provat per username, nom, llinatges i email, i funciona amb valors parcials però realitza un AND de tos els valors passats. La problemàtica i solució al problema del AND s'explica al punt K.4.
Per NIF, no existeixen cerques a l'API per atribut. S'hauria d'aplicar la solució descrita al subpunt anterior i només funcionaria amb el NIF sencer (no parcial) ja que és un atribut i les cerques internes per Atribut només accepten valors EQUAL i no LIKE.
A les solucions proposades faltaria afegir Autenticació/Autorització com es descriu aquí https://stackoverflow.com/questions/54482881/keycloak-custom-spi-rest-endpoint-with-authorization (NO PROVAT).

(K.2) Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre els següents camps: username, nom, llinatges, email o NIF.

A l'API de KeyCloak existeixen mètodes per fer una cridada que filtri per username, nom, llinatges i email a la vegada, és a dir, fa un AND de filtres: La solució de "a la vegada"(AND) es fer 4 cridades posant un valor a un sol camp. Així convertiria el AND en un OR.
No existeix filtre per NIF: En principi la solució pel NIF passaria per afegir serveis REST com els descrits veure punt K.1.

(K.3) Mètode per comptar usuaris que s'ajusten al filtre parcial sobre el camp nom-llinatges.

No existeix. Alternatives veure punt K.1.

(K.4) Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre el camp nom-llinatges.

A l'API de KeyCloak existeix un mètode per recuperar usuaris emprant filtre parcial sobre username, email, nom i llinatges. El problema es que internament la consulta fa un AND sobre els filtres: per exemple si cerc "nab" i l'assign a la cerca de nom i llinatges llavors només treu els usuaris on nom i llinatges contenen "nab" (per exemple Anabel Nabi). Per solucionar-ho s'han de fer dues cridades, una per nom i l'altre per llinatges i després ajuntar-les o emprar la solució proposada al punt (K.1)

(K.5) Mètode per comptar usuaris que s'ajusten al filtre parcial sobre el camp username.

No existeix. Alternatives veure punt K.1.

(K.6) Mètode per recuperar usuaris que s'ajusten al filtre parcial sobre el camp username.

A l'API de KeyCloak existeix un mètode per recuperar per filtre parcial sobre el camp username.

(K.7) Altres mètodes de comptar/recuperar per email o nif.

Per email s'aplicaria la cerca descrita en els punts K.5 i K.6, mentre que la cerca parcial per DNI s'aplicaria K.1 i K.2

PD: Altres millores a tenir en compte en una futura ampliació de l'API de Plugin de User Information: (a) Incloure mètodes per indicar si certes cerques estan disponibles. Per exemple la cerca per Certificat no està disponible a KeyCloak, d'aquí que hi hauria d'haver un mètode a l'API per indicar-ho. Per exemple "boolean isAvailableSearchByCertificate()" (b) Incloure més informació de l'usuari: id, xarxes socials, telèfons, notes, data naixement, data de creació, ... s'ompliria lo que el sistema de user information conté i la resta quedaria buit. (c) @acuevas-dgtic: Dins de les APIs Addicionals fer configurable un nombre mínim de caracters per iniciar la cerca i així la gent de Sistemes podrà anar ajustant segons l'entorn en que es trobi: Per exemple a DEV si cerques per "a" com a molt et surten unes 20 entrades. Supòs que ni punt de comparació per PRO que ves a saber si amb 4 caràcters encara et surten una burrada d'entrades. (d) @sgelabert-dgtic : recuperar des de les aplicacions una llista d'usuaris amb un rol determinat. (e) Limit: Seria muy cómodo tener un único método para hacer búsquedas textuales parciales en el que pudieras configurar los campos por los que se quiere filtrar. La idea seria tener un método similar a:

    public List<Resultat> consultaTextoParcial(
        String texto,
        boolean buscarEnCodigoUsuario,
        boolean buscarEnNombreApellidos,
        boolean buscarEnEmail,
        boolean buscarEnNif);

Así con un solo método se cubririan todos los casos posibles de búsquedas por texto parcial.

GovernIB / pluginsib-userinformation

KeyCloak: Estudi d'obtencio d'usuaris a partir de per part de DNI, part de username o part de nom-llinatge. #6