syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van Es <>
Subject Syncope vs NetIQ IM
Date Tue, 26 Jan 2016 13:38:07 GMT

I was invited by Francesco to elaborate on my NetIQ IM vs. Syncope findings
to explore on what I think might help in Syncope so that it would become a
stronger competitor/alternative. Bear in mind that I'm a self taught NetIQ
developer, have not looked at many other products and lack the time to
profoundly dive into Syncope. I might have missed some things here and
there ;)

The most important difference I guess is that customizing NetIQ IM does not
require me to program Java. Although I do have generic programming skills
and know Java, managing "big" Java projects is not my strong side. I
wouldn't know where to start if I wanted to create a custom functionality
or anything not implemented out of the box in Syncope e.g.

NetIQ does require programming, but that's allways in the Eclipse based IDE
they supply (or webinterface if you don't want the IDE) and is based on
rules/policies with ECMAscripting and/or XSLT stylesheets that only take a
reload to test. Deploying NetIQ IM feels more like "configuring", although
many would say it is a daunting programming task ;)

NetIQ IM is built around a directory with LDAP interface, which makes it
widely usable as a reference Identity Store without even needing to
provision external applications. Together with reversible password policies
this is a very strong characteristic because:

PWM ( is, in my opinion the best
Password Self-Service tool around, which relies on communicating with a
directory for (re)setting passwords, security questions and conforming to
password policies. PWM is now commercially adopted by NetIQ as the standard
password self-service interface for IM installations known as SSPR.

Although it takes getting used to, the "flow" of identities to and from the
central directory (called publisher and subscriber channels) are extremely
flexible to conditionally allow/place/rewrite indentities in target
applications or the local store. This concept of incoming and outgoing
channels, each completely programmable what to do with identities once they
"appear" is unmatched in my opinion. A special case is a "Loopback" driver
that fires as an identity gets created in the local directory, but loops
back to the directory, modifying/enchancing and emailing managers while
doing so on the fly. I know Syncope has virtual attributes, but it doesn't
even come close to what is possible in loopback drivers. This loopback
driver e.g. can take care of enabling accounts in connected systems on
first workday (based on startdate attribute) while being present in the
store long before, not because it's a feature of IM, but because the
loopback driver can inspect certain attributes and take actions under
certain circumstances in a not too difficult syntax embedded as a string of

Although a nightmare to develop, approval workflows are common ground in
NetIQ IM. There is no such thing as a single identity lifecycle (as I
understand Syncope) but many (approval) workflows depending on many
usecases. Differences like employee asking for new permission right (role),
which has to be approved by direct in line manager AND anyone from IT staff
pool (while sending mails to the web content manager to update workers
page). Which is different from Manager asking for an employee's role to be
removed or an IT Staff that has to push a break the glass emergancy button
(disable account anywhere, ignoring startdate). All these workflows have
(webbased) forms, which is why I'm investigating if Activiti could somehow
be used together with Syncope, but last time I checked making API/REST
calls from Activiti workflow was still in development.

So, looking at the above rambling one could distill the ultimate Syncope
feature that would make it stand up against commercial products: make it as
easy as possbile to extend functionality by injecting (ECMA)script hooks in
as many identity/policy decision points as possible, preferably chaining
them together in a multitude of provisioning flows where applicable.

Hope this all makes some sense ;)

Best regards,
If 'but' was any useful, it would be a logic operator

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message