On Thu, Jul 2, 2015 at 6:05 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 02/07/15 11:14, Kiran Ayyagari a écrit :
> > Hi Yaning,
> >
> > On Thu, Jul 2, 2015 at 4:28 PM, Xu, Yaning <yaning...@intel.com> 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.

>
> 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.


-- 
Kiran Ayyagari
http://keydap.com

Reply via email to