“Building Identity Journeys with Low Code”
with Mike Schwartz at APAC Digital Identity Unconference 2023
Modern authentication has evolved significantly. In the past, a single web page, typically a username/password form, would be presented to authenticate a person, and access to the website would either be granted or denied based on the outcome. Nowadays, modern identity services use a sequence of web pages to authenticate a person via a web browser. The web pages displayed can vary based on security assessment. For instance, if the authentication process seems unusual, such as when a person is using an unrecognized browser or logging in from a new location, additional steps may be necessary to ensure the person’s identity.
Authentication is just one part of the “identity journey,” which includes social login, registration, “forgot password,” two-factor credential enrollment, and consent, among other things. At a high level, the three most typical identity journeys are registration, sign-in (authentication), and forgot password (credential enrollment). This process of building identity journeys is also known as “identity orchestration” in the security industry.
As modern authentication is increasingly based on open standards, especially OpenID Connect, the question arises of how websites can enable the building of identity journeys as part of the OpenID Connect flow. In the past, Gluu exposed a mechanism called “interception scripts,” written in Java or Python syntax, which were highly powerful, allowing websites to build any type of authentication flow. However, creating such scripts required at least intermediate-level programming skills, and for more complex flows, it was better to be an experienced Java developer.
One significant challenge regarding the maintenance of these scripts is knowledge transfer. The original author of the scripts has deep knowledge of how they work, but how can they transfer the script to the next team? As the scripts are asynchronous, there is no sequential way to read them. Basically, the new team needs to invest a lot of time to study and understand the code.
In recent years, “low code” has emerged as a strategy to enable developers to use graphical tools to create programs. Some platforms even promise “no code” by providing pre-built components that perform all the tasks needed to create a working solution. However, “no-code” solutions suffer from one disadvantage, which is that if the platform designs haven’t provided the functionality, there is no way to accomplish the task. Given the diverse requirements for building identity journeys, a low code approach is better.
The Janssen Project, a Linux Foundation chartered group, was formed with the purpose of building a world-class OpenID Connect provider. In 2020, Gluu contributed the open-source code that it had developed since 2009 to provide an advanced starting point. The Gluu Server was the most certified OpenID Provider and was used in production by hundreds of companies, including a significant number of governments, financial institutions, large enterprises, and global security companies. Building on this, the project has continued to innovate rapidly, not only in functionality but also in tools to enable easy administration, cloud-native deployment, and to increase the transparency and quality of the CI/CD process. The Github URL for the Janssen Project is https://jans.io.
In 2021, the Janssen Project senior developers decided to build a low-code solution for identity journeys, following the success of similar platforms by large commercial, proprietary OpenID Connect vendors like ForgeRock and Ping Identity. There was no open-source low-code way to build these identity journeys, and the Janssen team projected that enabling developers to use this approach would attract a large community, especially with respect to Red Hat Keycloak, another popular (but difficult to customize) open-source identity platform.
After surveying several possible solutions to build a low-code identity orchestration solution, Jose Gonzalez, one of the lead developers at the Janssen Project, proposed an interesting idea: why not design a domain-specific language, or DSL, that specifically addressed the requirements for building web flows for identity orchestration. This approach was ultimately selected, and Agama was born. (Mike Schwartz picked the name Agama based on a visit to the San Antonia zoo reptile collection, where he saw some cute shield-tailed Agamas).
You can find an introduction to the Agama DSL in the Janssen documentation: https://docs.jans.io/head/admin/developer/agama/