[midPoint] New Kerberos connector, paging support questions

[František Dvořák]

Radovan Semancik píše v Čt 20. 04. 2017 v 09:39 +0200:
> 
> Thank you. Kerberos connector would be a nice addition to ConnId-
> compatible connector collection.
> 

We made a release, so there are binaries to play with. There are the
minor issues (the offset in page search), but everything should work.

> I agree that the paging behavior is quite strange. It is partially
> given by the fact that there is no count() operation in ConnId.
> However, the GUI frameworks need to know the number of all entries in
> the search to correctly display the paging information. Particularly
> Wicket framework expect two separate operations: count     and
> search. But that is not the case with ConnId. The paging mechanism in
> ConnId allows to pass the information about the number of entries as
> a product of the search. Hence two search operations. First one is
> used to get the number of all results, second one is used to get the
> actual results for the displayed page.
> 
> 

> BTW, if I remember correctly then ConnId offset starts at 1, not 0.
> Therefore offset=1 means request to return the entries from the
> beginning.
> 

OK, I think I understand it. Offset starts from 1, and it has nothing
to do with the initial query of page size 1. :-) Offset 0 would mean
"next" according to ConnId documentaton.

Btw. cookies are not supported, right? (it seems they got eaten by
midPoint) So support for "next" page (offset 0) is not theoretically
needed in the connector now?

There is also interesting limitation in ConnId. Sun IdM had separated
list and get operations (and optionally iterate operation in case of
optimal way of doing both: list+get), but ConnId has only the full
iterating. This is more painful in case of Kerberos, which has
operation for listing of principal names but any details must be
additionally fetched by the connector one-by-one. And reconciliation
process in midPoint works by calling a big executeQuery() first, and
then executeQuery() one-by-one.

The attributes intended for correlation and synchronization rules must
be returned already in the first call. But they won't be needed in most
cases, so theoretically there are possible some hacks using of
ALLOW_PARTIAL_ATTRIBUTE_VALUES query option for example. Or it would be
too much dirty hack?

Thanks,
  Frantisek