On 03/11/2014 11:29 AM, Massimiliano Perrone wrote:
Hi guys,
I hope to explain in a few words what we are doing with ConnID and IPA. Comments in-line.

On 03/10/2014 10:57 PM, Dmitri Pal wrote:
On 03/10/2014 03:14 PM, Petr Viktorin wrote:
On 03/10/2014 07:17 PM, Dmitri Pal wrote:
On 03/10/2014 08:24 AM, Petr Viktorin wrote:
On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote:
Hi all,

Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò
<ilgro...@apache.org <mailto:ilgro...@apache.org>> ha scritto:

On 31/01/2014 18:57, Dmitri Pal wrote:
On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote:
I am actually not sure if it is "lightweight" connector could
be better than a "loaded" connector (e.g. without proxy), from a
deployment point of view, unless you are saying either that (a) a
smart proxy is already available that can be reused
The idea can be reused as a starting point. IMO the easiest would
be to
look at the patches and use same machinery but implement different

or that (b) incorporating the smart proxy that we are going to
into FreeIPA will easily happen.

^ quote left here deliberately


We start to implementing a FreeIPA ConnId connector for Apache Syncope.
We have to implement all identity operations defined by the ConnId
I would like to know the implementation status of the Smart/Proxy and if
we can use it to all the identity operations.

I'm reviewing the Foreman Smart proxy patches now. They're not in the
FreeIPA repository yet. However the remaining issues were with
packaging, code organization, naming.

The Smart Proxy is now specific to Foreman provisioning; it is not a
full REST interface so it will probably not support all operations you

For a full REST interface, patches are welcome but the core FreeIPA
team has other priorities at the moment.  The RFE ticket is here:

For user provisioning you do not need a full REST api. You need to have
a similar proxy but just for user related operations.
So the smart proxy can be used as a model to do what you need to
implement for Syncope integration.

You'd be building two bridges (IPA--REST & REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part.

What are the operations you need to implement? Can you list them?

They were listed earlier in the thread, and [5].

It is usually easy to take something that is already working like smart proxy and change the entry points to the ones that you need. I am not familiar with the architecture of the connectors. Are they separate processes? Are they daemons? Are they forked per request? Connection to IPA needs to be authenticated. If the connection to IPA happens from a single process like smart proxy you do not need to worry about machinery related to authentication and session managment. It is already implemented. This is why I was suggesting to use smart proxy. IMO REST vs. JSON is not that big deal. They are similar. Doing things right from the authentication POV and session management are much harder. But if we do not see a value in using smart proxy even like a reference point for ConnID I would not insist.

Basically a ConnID bundle (ConnID is framework used by Apache Syncope to connect the external resources) is a Java library developed to invoke the following operations from Apache Syncope to the target resource:


For example, ConnID already has an Active Directory bundle [9] and an LDAP bundle [10].

As you already know, our goal is to develop a new bundle to invoke the provisioning operations on IPA server installation.

From "ConnID development" point of view, the first thing is to choose a right way (to read protocol/interfaces) to communicate with the server.

Briefly "the right way" needs:
*) a long term support interfaces;
*) an interfaces that allows all user / group provisioning operations;
*) a way which leaves ConnID developers totally independent from (in this case) the FreeIPA development.

Starting from this introduction we think that the right way is to use JSON-RPC interfaces, with particular attention to authentication and session management, as suggested by you.

Do we have to consider other critical factors before starting to work?

This seems reasonable.

Here are some other questions that you might want to ask yourself starting the work.
(there is no intent to scare you :-) )



Otherwise, we will instead specialize the CMD connector [12] to
feature the FreeIPA command-line interface (as suggested at the
beginning of this thread). There will be potentially need, in this
case, to include the ConnId connector server into the Syncope
deployment architecture, but this is a supported pattern.

Have you looked at JSON-RPC interface mentioned earlier in this
thread, and [6]? It might be cleaner to use that than the command-line

[1] http://syncope.apache.org/
[2] http://tirasa.github.io/ConnId/
[3] http://java.net/projects/identityconnectors/
[4] https://github.com/Tirasa/ConnIdFreeIPABundle

[7] http://www.freeipa.org/page/Documentation
[8] http://www.freeipa.org/page/V3/Smart_Proxy
[9] https://github.com/Tirasa/ConnIdADBundle
[10] https://github.com/Tirasa/ConnIdLDAPBundle

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to