[midPoint] New Kerberos connector, paging support questions

[Radovan Semancik]

On 04/23/2017 12:03 PM, František Dvořák wrote:
> 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?

I do not know for sure. But as far as I know we have done no systematic 
testing of paging cookies. So, if you are saying that they do not work 
then it is likely that they really do not work. Cookies was some kind of 
an afterthought. They are useful and all ... but they were not part of 
the original paging design. That's the reason why they probably do not 
work. Anyway, they are supposed to work and if they do not work I would 
consider that to be a bug.

You may create a bug report for that: 
https://wiki.evolveum.com/display/midPoint/Creating+a+Bug+Report

However, planned midPoint 3.6 is a feature-packed release, we have a lot 
of sponsored features. And together with bug fixes for subscribers those 
new features are currently the highest priority. Therefore I cannot make 
any promises about fixing the paging cookies.

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

Indeed. It is one of the known issues: 
https://wiki.evolveum.com/display/midPoint/ICF+Issues#ICFIssues-ReadandSearch

We have no easy solution for this, except for changing ConnId. Which can 
be done, of course. But it is not that easy. Especially that ConnId is 
used by (at least) two competing IDM systems. Any ConnId changes need to 
be handled with care.

What we do in LDAP connector is analysis of the filter. If it looks like 
"get" then we use the more efficient operation. Now this is probably the 
only practical way.

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

This is even more complex issue. There is a partial solution. There are 
two OperationOptions that allow return of partial results 
(ALLOW_PARTIAL_RESULTS,ALLOW_PARTIAL_ATTRIBUTE_VALUES). MidPoint is 
using them at some places and they seem to be a good optimization. But I 
do not think we have done optimization for your specific case. Anyway, 
these options together with ATTRS_TO_GET might be (theoretically) used 
for some optimization and might make your case efficient. But  it is 
likely that changes in midPoint will be needed for this to work.

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

Depends on where you do it. Connector should follow the ConnId contract 
which means the connector is essentially controlled by commands from 
midPoint. So I'm not sure how you would do this hack in a connector. The 
good solution would probably be for midPoint to use the OperationOptions 
in a less wasteful way. But this is not something that can be fixed in 
an hour. And we haven't see any critical need for this for any other 
connector that we support. Therefore we do not have any specific plan to 
do this now. So, you have the usual options:

https://wiki.evolveum.com/display/midPoint/I+Need+New+Feature

-- 
Radovan Semancik
Software Architect
evolveum.com