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:
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
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
We have to implement all identity operations defined by the ConnId
I would like to know the implementation status of the Smart/Proxy
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 .
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
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  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 ? It might be cleaner to use that than the command-line
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list