Connector Gateway

[Radovan Semancik]

Dear ConnId community,

We (Evolveum) have received a very nice contribution to identity
connector ecosystem from our partner NRI: Connector Gateway.

https://github.com/openstandia/connector-gateway/

Essentially, Connector Gateway turns around the connection pattern of
connector server. Instead of IDM system connecting to connector server,
the connector gateway connects to the IDM system. This approach has
substantial advantages, especially in cloud environments.

However, the connector gateway is a separate project now, which adds two
(or three) new components to the deployment. It would be nice if we
would be able to integrate the connector gateway concept with existing
ConnId framework and connector server code. That would significantly
simplify the deployment.

I would like to move the discussion here, also inviting the original
authors of the contribution.

From a technical side, integrating Connector Gateway client with ConnId
Connector Server should be relatively straightforward. However,
integration of Connector Gateway Server with Connid connector framework
does not seem to be easy at all. The problem is obviously the "server"
part, how would a component in a connector framework accept a
connection. Yet, this got me thinking. Some connectors may actually need
to listen/accept connections as well. Maybe we could use a similar
approach to support both the connector gateway and such "listening"
connectors in the future.

My idea is to expose connection handling method in ConnId facade (as an
optional connector capability) that would accept a Socket or
input/output stream or some other form of open connection. We would need
to do some work here to figure out how to do this in a platform
independent manner, as I guess we do not want to lock ourselves in for
Jetty or Tomcat or any other specific web server API. Then the connector
framework client (the IDM system) will need to listen for connections,
accept them, and call the framework together with the open connection
(donating a thread). Obviously, connectors will need to specify listen
parameters (TCP or Websocket, port, context path, etc.), and we have to
figure a way for a connector to do this. We can leave the details for later.

However, for now we can use a similar method to semi-hardcode the
connecor gateway server into the framework. We can implement a "handle
gateway request" method in the framework, that would expect an active
Websocket connection from connector gateway client. It will be the
responsibility of the connector framework client (IDM system) to listen
for the connections, accept them and pass them to the framework. It will
be semi-hardcoded now, and it can later evolve into the flexible method
that could be used by the connectors as well.

We (Evolveum) are willing to work on this concept, if it looks good to
you. What do you think?

Original mail in midPoint mailing list (for reference):
https://lists.evolveum.com/pipermail/midpoint/2023-June/007767.html

--
Radovan Semancik
Software Architect
evolveum.com

[Francesco Chicchiriccò]

Hi Radovan,
sorry for late reply.

In general I do believe that what described below would represent a nice improvement for scenarios where exposing a Connector Server instance to the wild is problematic, often matching cloud-based IdM deployments.

Hence, I believe such a contribution is more than welcome here, we only need to accomodate things nicely.

About technical, I was thinking that IdM systems are possibly already listening to an HTTP socket (to offer their RESTful services, for example), so it could be more efficient to re-use somehow that connection even for accepting Gateway Client requests, which will be then passed to the relevant connector instance.

Not sure how to proceed at this point: shall we start with some kind of PoC?

Regards.

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/

[Radovan Semancik]

Hi

On 15. 9. 2023 17:26, Francesco Chicchiriccò wrote:
> About technical, I was thinking that IdM systems are possibly already
> listening to an HTTP socket (to offer their RESTful services, for
> example), so it could be more efficient to re-use somehow that
> connection even for accepting Gateway Client requests, which will be
> then passed to the relevant connector instance.

Exactly. However, websocket is more than HTTP request/response. We need
to explore the details, yet I think if is feasible.

> Not sure how to proceed at this point: shall we start with some kind
> of PoC?

We have the NRI's project as a very nice starting point, we just need to
develop it further and try to integrate it with ConnId. Matus Macik from
our team can work on that. We will be working on a separate development
branch for now, exploring the possibilities. We will share our results
here, once we get something tangible.