Using open source for identity projects: 8 considerations

The use of open source in the enterprise is blooming as organizations seek to reduce time to implementation and hopefully reduce costs. A 2019 RedHat report on “The State of Enterprise Open Source” said that 95% of respondents found open source “strategically important.” 

When looking at the applications of open source in an enterprise setting, however, identity management does not always seem like a natural home. This may be because identity-related services are arguably one of the most complicated systems to design and build. Can open source be used wisely in an identity context and maintain security as well as usability?

8 considerations when choosing open source for identity projects

Thoughts about using open source often turn to fear, uncertainty and doubt (FUD). This is not without reason. The Equifax breach of 2018 is a good example of why FUD persists in open source use. The incident involved cybercriminals using brute-force attacks against the open-source Magento platform.

There are very good reasons to use open source. The choice means that someone else has done the groundwork so your developers don’t have to. In theory, multiple people (the open-source community) have looked at and verified the code. While this may mean the code has passed unit testing, it isn’t the same as functional testing. Therein lies the rub. Identity-led services are often multi-functional systems. The functional testing of these systems, the myriad user journeys and alt pathways can take the code down twists and turns that will open up exploits.

Open-source code can offer a good starting point for specific functionality within a wider identity ecosystem while your organization maintains control over the final application.

Before embarking on an open-source-led identity project, weigh several considerations. First, and perhaps most important, is your software development life cycle (SDLC) up to scratch? Just because you use open-source code does not mean you will be exempt from the usual SDLC processes. Open source is not a full-pass to an out-of-the-box application. It will require the same levels of testing and maintenance as any externally or internally developed system. Areas of consideration include:

1. Security and bloat

Open-source software is susceptible to code bloat. Once this happens it can be difficult to control security as a “bloatware effect” takes over. Bloatware is where functionality is increasingly added to code libraries resulting in greater difficulty in analyzing the software. As the code becomes bloated it becomes easier to hide malware. A recent example is the Octopus Scanner malware, which researchers found in 26 GitHub source-code repositories.

Open-source libraries, particularly those in the identity space, are perfect targets for malware. Repositories are set to always take the latest version of the open-source code (a best practice to ensure patches are integrated). If someone slips in malware, as in the case of Octopus Scanner, the update then incorporates this malware. Before you spot it, the malware is in your product and the rest becomes a painful history.

A lack of control over code can also lead to increased vulnerabilities in the final system. The whole requires careful analysis and testing. This can negate the time-saving aspect of using open source. In addition, if the open-source code is refactored, it can break its application within a given system.

2. Scalability

Identity services, especially those built for consumers, often require high scalability. When choosing an open-source project, scalability must be high up on your consideration list.

3. Interoperability

Many identity projects have multiple moving parts. They often use third-party components to add important functionality. For example, a consumer identity system may use a credit reference agency (CRA) to verify user attributes. Open source is unlikely to have the capability to interoperate with the third parties of your choice, forcing you to extend the open-source code.

4. Flexibility

How easy is it for an identity service, based on open source, to extend to different database storage, incorporate varying attributes, use different authorization and authentication options, translate protocols, etc.? Will you have to wait for the open-source community to add support for new standards such as OIDC CIBA, for example?

5. Future-proofing

Can you modify the functionality? Is it easy to change and add functionality as requirements change? Identity services are an ongoing concern. Customer expectations change over time, but the underlying service needs to persist. If you put all your efforts into using a certain open-source library, it can be difficult to move to a better and improved library that provides similar functionality: You may end up with an open-source version of vendor lock-in.

6. Support and maintenance

Many open-source solutions come with additional support packages. In some ways, this may seem to negate the use of open source. It may also cause issues if your in-house team develops the code down pathways outside the knowledge or remit of the support package. Similarly, maintenance can be an issue.

Identity services are at the coalface of digital interactions and need to be on top of the ever-changing face of the security landscape. As new exploits arise, identity services need to be able to modify system behavior, allow easy patching of outdated software, and add new capabilities to existing systems to close new gaps.

7. Identity expertise

Identity services require multidisciplinary expertise. This includes UI/UX knowledge, a deep understanding of privacy and regulatory compliance as well as a wide remit of security expertise. Using open-source code is only one aspect of creating an identity-related service. A well-designed and developed identity system requires a 360-degree approach that builds best-fit platforms for wide demographics. The code needs to follow that fit, not dictate it. Starting with code is the wrong way around. However, if the code can form a baseline to work from, then this can circumvent a lot of work.

8. Dependencies

Sometimes open-source libraries have dependencies. That is, when you install them, they install other associated libraries. If this happens, you can end up with many open-source libraries, some that are not needed. This can be a problem as some of the libraries can end up deprecated. When this happens, the open-source community will point to alternatives. This may mean a move to a new set of libraries. Alternatively, you will end up living with the deprecated library, which may well contain vulnerabilities that will never be resolved.

Use open source wisely

Identity services by their nature are highly dynamic. Often, identity services need to follow the dictates of ecommerce and customer expectations. The security landscape is such that identity systems and user attributes are a target. This means the system has to be flexible enough to handle change.

If you choose to use open source, do so with caution and pick and choose where you apply open source libraries. Ultimately, the design of identity systems must take the lead. Open source can augment a project, especially if chosen wisely. Choose a library that only offers the functionality that you actually want.