Le 02/07/15 13:25, Kiran Ayyagari a écrit : > On Thu, Jul 2, 2015 at 6:05 PM, Emmanuel Lécharny <[email protected]> > wrote: > >> Le 02/07/15 11:14, Kiran Ayyagari a écrit : >>> Hi Yaning, >>> >>> On Thu, Jul 2, 2015 at 4:28 PM, Xu, Yaning <[email protected]> wrote: >>> >>>> Hi Kiran, >>>> >>>> >>>> >>>> 1. The administrator may need to list all principal names, and >> then >>>> use the principal name he is interested in to get the Identity; >>>> >>>> 2. There may be too many principals to scan at once, so the system >>>> may need to get only a part of them at once, as Stefan pointed out; >>>> >>>> 3. We need to make Kerby compatible to Krb5, and it has >> implemented >>>> this interface as list_principals >>>> >> http://web.mit.edu/KERBEROS/krb5-1.12/doc/admin/admin_commands/kadmin_local.html >>>> ; >>>> >>> ic, so here is the case, it is mainly for the kadmin client and I would >>> prefer if kadmin takes care of >>> sorting and paginating after retrieving the principals rather than >>> offloading this to backends. >>> >>> The primary reasons is not all stores that are used by IdentityBackends >> may >>> support sorting or >>> pagination, for example not all LDAP servers support sorting and many >>> database libraries do not >>> support pagination(this is a client thing). >>> >>> I would like to propose an alternative design: >>> >>> Add search functionality to the IdentityBackend, i.e it accepts a search >>> pattern and return a Cursor >>> then kadmin will browse this cursor and prepares a suitable view of >>> principals. >>> We can have a search limit in this interface but we don't need a start >>> position cause the client can >>> navigate using Cursor (when the cursor implementation supports). >> I tend to disagree with Kiran, here. >> >> If a server does not support 'sort' and 'paged search', then there is no >> mean to use it as a backend. AFAICT, most of the existing LDAP server on >> the market support both controls. >> > this is not just for LDAP servers, but any of the 'store's that are used by > Kerby > say, there is one using Mavibot, we need to fetch *all* and perform a search > cause Mavibot doesn't natively offer a substring/wildcard search.
True. I was specifcially speaking about LDAP backend, I should have be explicit. > >> In any case, don't implement it on the client side : with millions and >> candidate, it will not only be slow, but it will also eat a hell lot of >> memory. >> > here the client is not just authenticating but is is an admin UI for > Kerby's database, > this client can sort, search and paginate perhaps with a wrapper backend > that > does all the functionality. > > My idea is not to enforce this requirement on each backend implementation. I'd rather suggest that the API expose a Cursor. The backends that support Sort and Paged Search would be favored, and the others, well, they will have to implement the Cursor interface.
