Discussion: Future of ConnId
91 views
Skip to first unread message
Radovan Semancik
Dec 10, 2019, 10:39:09 AM12/10/19
to conni...@googlegroups.com
Dear ConnId community,
I would like to start discussions about the future of ConnId.
ConnId originated from Sun Identity Connector Framework (ICF). ICF was
designed more than 10 years ago and it is quite understandable that the
design reflected state of the IDM art at that time. Current IDM systems
are miles away from that and the original ICF is no longer sufficient
for current needs. It is quite clear that we need to do something about it.
For those of you that are not aware of the situation: I have maintained
a list of ICF issues during all those years. It can be found in the
midPoint wiki:
https://wiki.evolveum.com/display/midPoint/ICF+Issues
There is also a recent survey of midPoint features, that included some
questions about ConnId. This may be also a valuable insight into the
needs of ConnId users:
https://wiki.evolveum.com/display/midPoint/MidPoint+2019+Survey+Results#MidPoint2019SurveyResults-ConnectorsandConnIdFramework
ConnId project is quite a sleepy one. It is no big secret that it was
just two entities driving the development during last years: Tirasa and
Evolveum. I dare to say that both Francesco and me are quite aware of
the situation and we are willing to do something about it. The usual
problem is, of course, time and resources. However, it looks like there
may be at least some resources on our side during 2020.
Both Tirasa and Evolveum were making small improvements to ConnId during
last years. However, the changes that we need to make now are much more
substantial. I would not like to do any unilateral changes in ConnId as
the whole point of ConnId is cooperation and interoperability. Therefore
I have reached out to Francesco. We have met early this year on TIIME
workshop (https://tiimeworkshop.eu/). But the time was too short for the
two of us to achieve anything productive. And the reactions from the
audience and the community at large were a bit disappointing. Therefore
I have recently contacted Francesco again. And we have agreed to discuss
the future of ConnId on an public audio/video conference that I have
volunteered to set up. I would like to do this using a conference as
there is I expect lot of brainstorming and informal exchange of ideas.
I'm planning to set up the videoconference approximately in mid-January.
I will send an invite to this list and everybody is more than welcome to
join. As it looks like that most interested parties are located in
Europe, I plan to set up that is convenient for European time zones. But
in case that there is someone from different part of the world please
let me know, we can perhaps make it more friendly to other time zones.
--
Radovan Semancik
Software Architect
evolveum.com
I would like to start discussions about the future of ConnId.
ConnId originated from Sun Identity Connector Framework (ICF). ICF was
designed more than 10 years ago and it is quite understandable that the
design reflected state of the IDM art at that time. Current IDM systems
are miles away from that and the original ICF is no longer sufficient
for current needs. It is quite clear that we need to do something about it.
For those of you that are not aware of the situation: I have maintained
a list of ICF issues during all those years. It can be found in the
midPoint wiki:
https://wiki.evolveum.com/display/midPoint/ICF+Issues
There is also a recent survey of midPoint features, that included some
questions about ConnId. This may be also a valuable insight into the
needs of ConnId users:
https://wiki.evolveum.com/display/midPoint/MidPoint+2019+Survey+Results#MidPoint2019SurveyResults-ConnectorsandConnIdFramework
ConnId project is quite a sleepy one. It is no big secret that it was
just two entities driving the development during last years: Tirasa and
Evolveum. I dare to say that both Francesco and me are quite aware of
the situation and we are willing to do something about it. The usual
problem is, of course, time and resources. However, it looks like there
may be at least some resources on our side during 2020.
Both Tirasa and Evolveum were making small improvements to ConnId during
last years. However, the changes that we need to make now are much more
substantial. I would not like to do any unilateral changes in ConnId as
the whole point of ConnId is cooperation and interoperability. Therefore
I have reached out to Francesco. We have met early this year on TIIME
workshop (https://tiimeworkshop.eu/). But the time was too short for the
two of us to achieve anything productive. And the reactions from the
audience and the community at large were a bit disappointing. Therefore
I have recently contacted Francesco again. And we have agreed to discuss
the future of ConnId on an public audio/video conference that I have
volunteered to set up. I would like to do this using a conference as
there is I expect lot of brainstorming and informal exchange of ideas.
I'm planning to set up the videoconference approximately in mid-January.
I will send an invite to this list and everybody is more than welcome to
join. As it looks like that most interested parties are located in
Europe, I plan to set up that is convenient for European time zones. But
in case that there is someone from different part of the world please
let me know, we can perhaps make it more friendly to other time zones.
--
Radovan Semancik
Software Architect
evolveum.com
Francesco Chicchiriccò
Dec 10, 2019, 10:44:37 AM12/10/19
to conni...@googlegroups.com
Thanks Radovan for putting this e-mail together and for your commitment to maintain and further improve ConnId.
I hope that others are interested in this topic as well, and also willing to contribute actively to this barebone of open source identity provisioning.
Speak you next January.
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
I hope that others are interested in this topic as well, and also willing to contribute actively to this barebone of open source identity provisioning.
Speak you next January.
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Radovan Semancik
Jan 15, 2020, 7:32:28 AM1/15/20
to conni...@googlegroups.com, midPoint General Discussion
Dear community,
As I have announced earlier
(https://groups.google.com/d/msg/connid-dev/o3zsI40wFBA/_yQsWMIUBgAJ), I
plan to initiate a discussion about future of ConnId. This is something
that should not be taken lightly, therefore I'm starting to put together
all the data that may be relevant for the discussion. I would like to
share those data and my preliminary agenda with you before the actual
discussions, so everybody may be properly prepared.
First of all, we have conducted a survey among midPoint users last year.
There was a section of this survey that is related to ConnId. I have
took the time to compile detailed results of this survey:
https://wiki.evolveum.com/display/midPoint/MidPoint+2019+Surver%3A+ConnId-related+results
It looks like most people have mixed feelings about ConnId. There is a
lot of positive feelings, but also negative feelings. I can understand
that and this is one of the purposes of those discussions. Also, it
looks like most people would like to see support for complex attributes.
This is something that is also a pain point for us. There are also other
issues in ConnId.
My goal would be to think about ConnId 2.0. There are too many issues
and good solutions to those issues would require major updates and,
quite likely, also some incompatibilities.
My personal list of topics to discuss includes:
1. Schema and Identifiers
* Support complex attributes. Keep existing schema "language"? Or use
something that is more suitable?
* Clean up the schema, e.g. make the old __NAME__ and __UID__ optional.
* Clean up the concept of identifiers. E.g. allow clean use of both
entryUUID and DN at the same time.
2. Remote Connector Servers
Both Java and .NET connector servers are under-maintained (to be
politically correct). We have been overlooking them for a long time. We
have to do something with that. My proposal:
* Maintain Java server and gradually modernize it (e.g. improve logging,
error handling, etc.)
* Drop .NET server. Ancient AD connectors based on .NET are long gone,
therefore there seems to be very little incentive in maintaining the server.
3. API/SPI Operations
* Create new GetApiOp and GetOp, to split search and get. This should be
more natural and it should reduce complexity in some connectors.
* Create new CountApiOp and CountOp for object counting. Very similar
parameters to existing search methods.
* We have too many "update" operations now. UpdateDelta is clearly
superior to all others. Do we still keep the old operations?
4. Result handlers
What to do with those pesky things? It looks like they just get into the
way most of the time. We should at least make them disabled by default
in ConnId 2.
5. Asynchronous operations
How to support operations that do not return immediately? E.g.
operations that implement "manual provisioning"?
6. Misc little things
* Clarify definition of runAsUser, maybe rework the parameters to
properly use identifiers
* Improve the documentation
7. Testing
* Does anyone know how the testing framework really works? Is it
sufficient for our needs?
* How to include connector server in testing suite?
8. Low priority issues (not in scope)
Those are things that deserve some attention, but I would leave them for
later:
Capabilities, versioning, error handling, synchronization improvements,
service accounts, transactions, entitlements
And then the BIG QUESTION:
How do we go about this? Revolution or evolution? Do we re-write the
code? We can get rid of that CDDL and replace it with a more reasonable
license. We can also get rid of other legacy and troublesome parts. But
it will be a huge amount of work. Or do we evolve existing code? That
would mean that we will need to stick with CDDL pretty much forever. But
it may be much more feasible approach.
Of course, this is not a plan that can be implemented in a couple of
months. This will require a lot of resources and funding. It may take
years to get there and I'm not promising any particular dates or
deliveries here. I just want to make sure that we all have the same
goal. That we can agree on the design. And then we can think about
practical ways how to implement that.
I would like to make this a live discussion (video conference) rather
than a mailing list thread because there are many options to consider.
Especially for rewrite/evolve, schema and async questions. We need a bit
of brainstorming there. I will summarize the results after the
brainstorming so the community will not be kept in the dark.
I expect that the braninstorming wil take place in late January. I will
agree on a date/time with Francesco directly as I do not want to bother
the entire community with this. I will announce the dates in ConnId
mailing list and everybody is welcomed to join. If someone really wants
to make sure that the date suits them please let me know directly.
I'm cross-posting this to both ConnId and midPoint mailing lists, as I
expect that this may be interesting for midPoint community as well. All
further communication will be kept on ConnId mailing list, therefore
anyone interested in those discussions should join/watch connid-dev
mailing list.
As I have announced earlier
(https://groups.google.com/d/msg/connid-dev/o3zsI40wFBA/_yQsWMIUBgAJ), I
plan to initiate a discussion about future of ConnId. This is something
that should not be taken lightly, therefore I'm starting to put together
all the data that may be relevant for the discussion. I would like to
share those data and my preliminary agenda with you before the actual
discussions, so everybody may be properly prepared.
First of all, we have conducted a survey among midPoint users last year.
There was a section of this survey that is related to ConnId. I have
took the time to compile detailed results of this survey:
https://wiki.evolveum.com/display/midPoint/MidPoint+2019+Surver%3A+ConnId-related+results
It looks like most people have mixed feelings about ConnId. There is a
lot of positive feelings, but also negative feelings. I can understand
that and this is one of the purposes of those discussions. Also, it
looks like most people would like to see support for complex attributes.
This is something that is also a pain point for us. There are also other
issues in ConnId.
My goal would be to think about ConnId 2.0. There are too many issues
and good solutions to those issues would require major updates and,
quite likely, also some incompatibilities.
My personal list of topics to discuss includes:
1. Schema and Identifiers
* Support complex attributes. Keep existing schema "language"? Or use
something that is more suitable?
* Clean up the schema, e.g. make the old __NAME__ and __UID__ optional.
* Clean up the concept of identifiers. E.g. allow clean use of both
entryUUID and DN at the same time.
2. Remote Connector Servers
Both Java and .NET connector servers are under-maintained (to be
politically correct). We have been overlooking them for a long time. We
have to do something with that. My proposal:
* Maintain Java server and gradually modernize it (e.g. improve logging,
error handling, etc.)
* Drop .NET server. Ancient AD connectors based on .NET are long gone,
therefore there seems to be very little incentive in maintaining the server.
3. API/SPI Operations
* Create new GetApiOp and GetOp, to split search and get. This should be
more natural and it should reduce complexity in some connectors.
* Create new CountApiOp and CountOp for object counting. Very similar
parameters to existing search methods.
* We have too many "update" operations now. UpdateDelta is clearly
superior to all others. Do we still keep the old operations?
4. Result handlers
What to do with those pesky things? It looks like they just get into the
way most of the time. We should at least make them disabled by default
in ConnId 2.
5. Asynchronous operations
How to support operations that do not return immediately? E.g.
operations that implement "manual provisioning"?
6. Misc little things
* Clarify definition of runAsUser, maybe rework the parameters to
properly use identifiers
* Improve the documentation
7. Testing
* Does anyone know how the testing framework really works? Is it
sufficient for our needs?
* How to include connector server in testing suite?
8. Low priority issues (not in scope)
Those are things that deserve some attention, but I would leave them for
later:
Capabilities, versioning, error handling, synchronization improvements,
service accounts, transactions, entitlements
And then the BIG QUESTION:
How do we go about this? Revolution or evolution? Do we re-write the
code? We can get rid of that CDDL and replace it with a more reasonable
license. We can also get rid of other legacy and troublesome parts. But
it will be a huge amount of work. Or do we evolve existing code? That
would mean that we will need to stick with CDDL pretty much forever. But
it may be much more feasible approach.
Of course, this is not a plan that can be implemented in a couple of
months. This will require a lot of resources and funding. It may take
years to get there and I'm not promising any particular dates or
deliveries here. I just want to make sure that we all have the same
goal. That we can agree on the design. And then we can think about
practical ways how to implement that.
I would like to make this a live discussion (video conference) rather
than a mailing list thread because there are many options to consider.
Especially for rewrite/evolve, schema and async questions. We need a bit
of brainstorming there. I will summarize the results after the
brainstorming so the community will not be kept in the dark.
I expect that the braninstorming wil take place in late January. I will
agree on a date/time with Francesco directly as I do not want to bother
the entire community with this. I will announce the dates in ConnId
mailing list and everybody is welcomed to join. If someone really wants
to make sure that the date suits them please let me know directly.
I'm cross-posting this to both ConnId and midPoint mailing lists, as I
expect that this may be interesting for midPoint community as well. All
further communication will be kept on ConnId mailing list, therefore
anyone interested in those discussions should join/watch connid-dev
mailing list.
Keith LeValley
Jan 17, 2020, 1:36:20 AM1/17/20
to connid-dev
I first wanted to say thank you for all the work you have done over the years to keep this project alive. I am relatively new to identity management and am very fascinated by ConnID as I think this open source standards based approach is going to be the future.
I think one of the barriers that is making it difficult for me to join in this project is the learning curve and the lack of training materials. In the past when I have wanted to learn a new skill I have really just did a search in YouTube, but it is really challenging to find good tutorials on developing with ConnID. Having said that, I would be very interested in attending. I am US based so if it would be possible to schedule this sometime in the afternoon EU time, that would make it much easier for me to attend.
davy...@outlook.com
Jan 19, 2020, 12:31:25 AM1/19/20
to connid-dev
What to do resources that are giving you a penalty when you make to many request? Should connid be made aware of this?
Radovan Semancik
Jan 23, 2020, 7:43:12 AM1/23/20
to conni...@googlegroups.com
Dear ConnId community,
After an agreement with Francesco I have scheduled our design meetings
to Monday, 3rd February, 3pm CET.
The meeting is public. You are all invited to join the meeting using Zoom:
https://zoom.us/j/830534129
Meeting ID: 830 534 129
(Zoom client works perfectly in Linux. Otherwise we wouldn't use it.)
Rough agenda of the meeting is in the quoted mail below. The meeting is
scheduled for 1 hour, but we are free to talk as long as we want to.
After an agreement with Francesco I have scheduled our design meetings
to Monday, 3rd February, 3pm CET.
The meeting is public. You are all invited to join the meeting using Zoom:
https://zoom.us/j/830534129
Meeting ID: 830 534 129
(Zoom client works perfectly in Linux. Otherwise we wouldn't use it.)
Rough agenda of the meeting is in the quoted mail below. The meeting is
scheduled for 1 hour, but we are free to talk as long as we want to.
Radovan Semancik
Feb 3, 2020, 12:42:38 PM2/3/20
to conni...@googlegroups.com
Hi,
We had our discussion. And we have results and decisions. The notes are
here:
https://connid.atlassian.net/wiki/spaces/BASE/pages/707002369/ConnId+2.0.0
We had our discussion. And we have results and decisions. The notes are
here:
https://connid.atlassian.net/wiki/spaces/BASE/pages/707002369/ConnId+2.0.0
Radovan Semancik
Mar 19, 2020, 11:32:59 AM3/19/20
to conni...@googlegroups.com
Dear ConnId community,
I'm afraid that due to the pandemic and other events we have to postpone
our plans to proceed with ConnId 2.x development. I hope that all of you
are OK and that we can get back to it when all of this is over.
I'm afraid that due to the pandemic and other events we have to postpone
our plans to proceed with ConnId 2.x development. I hope that all of you
are OK and that we can get back to it when all of this is over.
Reply all
Reply to author
Forward
0 new messages