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.

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

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