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
actually
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
commands.
or that (b) incorporating the smart proxy that we are going to
develop
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
framework.
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
need.
For a full REST interface, patches are welcome but the core FreeIPA
team has other priorities at the moment. The RFE ticket is here:
https://fedorahosted.org/freeipa/ticket/4168.
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:
AUTHENTICATE
CREATE
UPDATE
UPDATE_ATTRIBUTE_VALUES
DELETE
RESOLVE_USERNAME
SCHEMA
SEARCH
SYNC
TEST
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?
Massi
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
interface.
[1] http://syncope.apache.org/
[2] http://tirasa.github.io/ConnId/
[3] http://java.net/projects/identityconnectors/
[4] https://github.com/Tirasa/ConnIdFreeIPABundle
[5]
http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html
[6]
https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html
[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
--
Massimiliano Perrone
Tel +39 393 9121310
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Apache Syncope PMC Member
http://people.apache.org/~massi/
"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
