Part 6: Engineering challenges - Connectors

Intro

Part 1: The Datastore

Part 2: Connectors

Part 3: The Sync Engine

Part 4: The Workflow Engine

Part 5: The Customers and What to deploy?

Part 6: Engineering challenges - Connectors

Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?

Part 8: IAM People Management challenges

Now that we’ve discussed what the next generation Identity Management (IdM) platform should look like and what needs to be built, let’s dive into the technical challenges that come with implementing connectors. This section is quite technical, so if you’re expecting a comparison of products or pricing, you may want to skip ahead.

Connectors are the backbone of any IdM system, facilitating the import and export of data efficiently. Let’s explore the hurdles a newly appointed engineering manager will face and why, in some cases, they might prefer to run the other way.

General considerations

While it’s common practice to implement unit tests with high code coverage, the real necessity for connectors is comprehensive end-to-end integration tests. Unit tests often cover basic functionality with controlled data but fail to simulate real-world challenges such as authentication failures, timeouts, performance degradation, or unexpected input (like HR systems repurposing data in unpredictable ways). Unit tests fail to simulate a change in behavior caused by connected system upgrades, reconfiguration, etc.

Integration tests need to target all supported systems, which presents a significant challenge: how do you configure and maintain these test environments? Most software developers (SDEs) lack the expertise to set up complex systems like DB2, OpenLDAP, DirX, or Domino in a realistic manner. Managing multiple versions of each system (for example, Oracle client 11g behaves differently from 8i; DB2 on NT is not completely the same as DB2 on AS/400), navigating licensing issues, and ensuring proper configuration in test environments are tasks that often fall outside the typical skill set of an SDE.

Given these complexities, many teams attempt to outsource this task. However, even when outsourced, the responsibility for system failures remains on the internal team. In many cases, the engineering manager will find themselves setting up virtual machines, configuring networks, and troubleshooting environments to get integration tests running smoothly. Being a manager, I had to put my hands on those VMs, containers, virtual subnets, set up NAT and routing, configure whatever had to be configured, fix what had to be fixed. I just needed a result, ASAP, and that was one of the options - DIY.

Despite the difficulties, integration tests are critical for ensuring the success of IdM connectors, though they are expensive and time-consuming to maintain.

Let’s talk about individual connectors now.

SCIM

SCIM (System for Cross-domain Identity Management) is a standard for identity management in cloud environments which seems to be more or less successful and becoming #1 in the cloud-world.

it’s essentially a JSON/REST-based connector with a predefined schema and some extensibility. While SCIM promises standardization, implementations vary widely.

For instance:

• Properties like User:active may be optional but still sent by some servers. If the value is inconsistent (e.g., one side expects false while the other returns true), it can lead to endless PATCH requests.
• Multi-valued property handling and the order of elements returned may also cause issues, depending on the server.
• Empty and null values handling. The protocol defines empty elements could be omitted. Ok. This introduces a bit of delta PATCH request generation challenges as you want to submit only changes, and not the whole object.
• Reconciling delta queries often relies on timestamps instead of counters, leading to inefficiencies and potential inconsistencies.

One of the biggest drawbacks is the lack of modern, passwordless secure authentication methods in SCIM protocol. Basic authentication and bearer tokens (often transmitted over public networks) remain common, though they carry security risks. Mutual TLS authentication helps but isn’t foolproof. Moreover, SCIM implementations are dependent on DNS and PKI for certificate validation, which can degrade performance in environments where access to external services is restricted.

Being dependent on DNS and PKI in terms of Certificate Revocation Lists (CRL) Distribution Points (CDP), you may face performance degradation due to extra calls (to CDPs) needed to validate presented certs to be not in a list of revoked certs (CRLs). Your operation system itself makes those calls and caches those lists; however, customers do very often disable caching (to be more secure) or block accesses to any external websites (to be even more secure) and the whole thing just breaks – not even mentioning air-gapped environments with internal certs, it’s the whole other world.

I’m yet to see ‘Proof-of-Possession (PoP) tokens’ used for authentication; however, those would require your client to be hosted in a cloud.

Despite these challenges, SCIM is a robust connector for cloud-based environments, but it requires constant updates and custom templates for each connected system.

LDAP

LDAP (Lightweight Directory Access Protocol) remains prevalent in on-premises environments, despite the rise of cloud-based services. While the basic functionality of LDAP is well understood, supporting various authentication mechanisms, schema extensions, and delta imports across different LDAP server implementations (like OpenLDAP or Active Directory) can be daunting

I won’t be talking about challenges to implement various authentication (binding) mechanisms. They are all very well known, from a simple bind with basic authentication, to Kerberos and mutual certificate-based authentication. All I can say is: hire an LDAP sysadmin, yesterday.

Going back to challenges, the main problem is not the implementation, but a variety of things to support. Challenges include:

• Half a dozen of authentication methods

1. Basic auth / simple bind
2. Kerberos from a non-domain joined machines
3. Kerberos with NAT environments and local DNS servers faking _sav records to work around IPs mismatching – when a target DC integrated DNS returns a real, non-NATed IPs
4. Group-Managed Service accounts
5. Cert-based auth
6. An API to safely rotate credentials on a regular basis.

• Separate credentials for containers or domains
• LDAP schema and partition (domain) detection
• Delta import strategies

1. AccessLog (and to make it complicated, AccessLog is not enabled by default when you install OpenLDAP, be ready to spend half a day enabling an overlay and creating a policy if you know how to)
2. ChangeLog
3. Timestamp
4. USNChange

• Supporting delta import strategies that do not bring deletions;
• Structural and auxiliary LDAP classes;
• Defining an algorithm of choosing the one and only objectClass for imported objects, finding the leaf of the object classes tree, constructing the final list of properties bound to that class. And having customers complaining that they don’t see objectClass=X in the connector as they think, that should be the final class and your connector thinks differently
• Provisioning Hierarchy to create missing containers when provisioning new users; various DN components and their meaning. Objects do not have to have a DN like CN=user1,OU=Test,DC=Contoso,DC=Com. It could very well be uid=User2,CN=Test,O=Contoso. To make it completely insane, consider uid to be a multivalued string with no immutable anchor like ObjectSID present at all.
• The need to import from selected containers only (and how it affects AD DS recycle bin and deletions on delta imports)
• Choosing right anchors for selected directory (AD DS users have got ObjectGUID)
• AD DS Recycle Bin – what happens when you enable it and when you don’t use ReplicateDirectoryChanges permissions (and why you don’t want to grant ReplicateDirectoryChanges to your connector account) but simply read from LDAP as if you were using LDP.exe
• And the last, but not the least important – integration of other products like MS Exchange or M365/Entra ID with AD DS and how they affect Exchange-related attributes in AD DS.

So, the biggest challenge is not coding but having proper technical specs authored before you start.

I’m not mentioning password sync from AD DS (using password filters and services like MIM PCNS), I’m not mentioning password sync into connected systems (as for example OpenLDAP passwords could be hashed and salted with SHA instead of being sent as a plain text) – let the future be passwordless.

I’m not mentioning the need to implement 3-step user creation process for some directories: create a disabled users with an empty password, reset a password, enable a user – you will face all that later.

An LDAP sysadmin is essential for configuring these environments and ensuring they operate smoothly. Without one, managing LDAP connectors becomes a time-consuming and error-prone process.

ODBC/JDBC

Similar to LDAP, ODBC/JDBC connectors face challenges due to the variety of relational database management systems (RDBMS) and their unique requirements. Differences in SQL dialects, authentication methods, and schema structures can make it difficult to build a one-size-fits-all solution.

Challenges include:

• Initial Connector Setup. Even having a step-by-step guide published we were getting complains that it is too complicated. Well, yes, it is. You either get a generic DB connector that can do everything or you get a pre-canned configuration to target a specific product only. Very often customers are confused by connectors vs configurations as they don’t know the difference.
• Creating a DSN file with connection details. Somehow, some consultants don’t know what ODBC/JDBC drivers are and that web sites like ConnectionStrings.com - Forgot that connection string? Get it here! do exist. You may end up publishing sample DSNs for every database engine you support to help them.
• Schema discovery. Flexibility comes at a cost of complexity. I’ve seen customers using tables and views 99% of time as they were failing to configure SQL SPROC calls or write their own SQL queries correctly.
• Choosing a proper anchor. It has nothing to do with coding. It’s all about IAM consulting. Majority of failures happen here. If we were only able to publish IAM best-practices on choosing right anchors…
• Choosing right DNs. SQL records do not have DNs, they do have (ideally, but not always, immutable) anchors. However, when you bring a record of a user with id=1 and a group with id=1 into connector space, you can still distinguish them by an object type, but having a property owner=1 on a group object imported, how would you know whether it points to a group or to a user? In a real world, you don’t have unique IDs across all object types. So, you need a DN. Say, CN=1, OBJECT=User and CN=1, OBJECT=Group.
• Supporting references. Now that you have a DN and can distinguish users from groups, you need a view, that will either convert owner=1 into owner = <DN> with an object type included, or you need an extra column with a hint, what object type to be used. So, you want your references pointing to anchors or DNs. Otherwise, it’s not going to work. And you’ll have to spend some time educating your customers what all this is about and how to use it. Or just ship a pre-canned configuration
• Supporting deltas. With a rare exception, RDBMS do not offer change tracking mechanisms. That means that you’ll have to support generic delta import strategies (multiply that by a number of SQL dialects):

1. Triggers and delta views
2. Watermarks
3. Snapshots

• Supporting prepared statements
• Supporting pagination (do you want to read 1M objects in one batch? Will it lock a connected table?)

What you may also expect is customers using your GSQL connector not in a way you expect, e.g. provisioning and manipulating AS/400 users by calling DB2 stored procedures that execute system commands – instead of buying an LDAP -> AS/400 gateway from a 3rd party vendor. Or using a main instance for export and a read-only replica for imports, having a 1-hour replication delay and complaining about export-change-not-reimported errors.

A knowledgeable database administrator is crucial for navigating these challenges, especially when supporting multiple versions of RDBMS in test environments.

PowerShell / Scripting

PowerShell and other scripting connectors offer flexibility but come with their own set of challenges.

The main catch here would be an approach to take. You can try to develop a generic PowerShell Connector that simply maps each ECMA2 method to a proper script. Developing a set of scripts to manage let’s say Lync users, won’t be way easier than a custom C# connector. Yes, a bit faster to develop (and almost impossible to troubleshoot and test, unless you’ve authored TestHarness.ps1 ) but still, you’ll have to understand the whole framework. The other approach could be to return simple PowerShell objects - GitHub - sorengranfeldt/psma: Powershell Management Agent for FIM2010 and MIM2016 and convert those PS Objects into connector framework objects during runtime.

Either way, you won’t face challenges other than authenticating to remote systems in various ways, impersonating a script running vs providing PS Credential object. And you’ll have to choose whether to store your scripts as a part of your connector config, or as a link to a local file. And timeouts. Those are real. A long-running PS script, establishing a remote PowerShell session and hanging for no reason (ok, there always a reason, something failed on the other side) is what I was facing supporting PS connectors.

In many cases, in-house IAM teams use PowerShell connectors to repurpose existing scripts, but this can lead to performance issues if the scripts are not optimized for production environments. Be ready to provide ‘commercially reasonable support’ for those cases.

Replace PowerShell with ZSH / KSH / BASH and you’ll get the same challenges.

Webservices

Web services connectors (REST/SOAP) offer extensive customization but can be challenging to implement correctly. Authentication methods, schema discovery, and import/export flow design are common pain points.

Reality is, it is too complicated to be used by small customers. And if we’re targeting consultants, let’s see what can go wrong here:

• Authentication methods, a lack of modern ones – too many options to support. From basic and windows integrated, to bearer tokens, OAuth and OIDC, managed identities, and everything else
• Schema discovery for REST (excluding SCIM). REST APIs often require manual schema discovery, which can lead to inconsistencies. And you have two options how to save your schema – as an XML/JSON file to be parsed by your runtime, or as a ‘generated.dll’ – a real .net class with all the properties to load that class using .net reflection. For former is easier, the latter is faster (but so buggy, as .net locks a DLL when you do Assembly.Load())
• Schema discovery for SOAP. You expect your counter party to provide you with WSDL and instead of that you get a document with policies, duplicated endpoint names, incomplete schemas, schemas pointing to internet resources your machine has no access to and so on. And while WSDL documents are some much better than manual REST/JSON, they are so often broken that the amount of support cases you might get is unreasonably high.
• Import / Export flow designers. WYSIWYG and drag-and-drop seem to be the right approach, yet building blocks shouldn’t be limited to one specific language only.

Building robust web service connectors requires not only technical knowledge of the target systems but also thorough documentation and ongoing updates to keep pace with changes in the external APIs

Having a previous experience with SAP R/3 (and other random things like DB2, AS/400, OpenLDAP, Sun One DSE, *BSD; Lotus Domino; once being a penetration tester, targeting AD DS and Oracle / Interbase DBs) it still took me a couple of days to author ‘Deploying SAP NetWeaver AS ABAP 7 ’ document to explain how you expose proper BAPIs as Web Services in SAP ECC and few more days to author ‘Authoring SAP ECC 7 Template for ECMA2Host ’ explaining how to create a Web Service connector template to implement basic user provisioning from Entra ID to SAP ECC . In a real world, you most probably don’t have a standalone SAP ECC instance with one mandate, but you have SAP CUA in-place with all systems connected, and you don’t just manipulate users, you have to manage: local and global activity groups, profiles, roles, systems and licenses, you have to implement delta tracking on the SAP side, you have to convert group:member into user:memberOf and so on.

Very often IAM vendors substitute connectors with templates in their marketing materials. So, when one says ‘We offer 1000 integrations’, most probably, it means just one Web Service connector with 1000 templates. And you will need a separate team to author those templates and keep them in up-to-date condition. The same applies to SCIM connector.

Conclusion

The technical challenges associated with building and maintaining IdM connectors are numerous. A strong team of system administrators, database administrators, and developers is essential for success. Without this support, even the most talented engineering manager will struggle to maintain reliable integration tests and production environments (and, most probably, will be trying their luck for no reason).

Previous: Part 5: The Customers and What to deploy?

Next: Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?