What is a bespoke identity journey?
After you hit Login on any protected website or mobile application of a domain, your first order of business is to authentiate yourself. How you do that depends a lot on the capabilities of that domain. Sometimes our only option is username and password. But today, lots of domains support social login or two factor authentication.
But what if you’re new to the domain? Or what if you forgot your password, or lost your two factor authentication thingy (i.e. it fell in a deep body of water…)
When you want to build the world’s greatest user experience, one reality you may face is that the page with the most “hits” is your login page. To make the world’s greatest service, you also need a world class identity experience. Extra friction during registrations may lead to expensive drop off. And not surprisingly, your organization is a special flower, with some of its own policies, procedures, fraud detection, alerting, monitoring, testing, and CI/CD requirements.
The word “bespoke” is an adjective that means “custom-made” or “made to order.” Like a well designed machine, having identity journeys that “fits” your domain makes sense because it is durable, low maintenance and creates a positive impression of your brand. World class identity journeys are essential to building trust with your customers.
Agama is an effort lead by the Linux Foundation Janssen Project to standardize how Identity Providers (“IDPs”) build identity journeys. In addition to the orchestration syntax (i.e. the Agama domain specific language), it is also a packaging standard for project archive (i.e. what’s in the zip file).
Because identity journeys are a collaborative effort for your domain, using a low code approach increases project reusability, and minimizes the engineering time for knowledge-transfer. Here are a few tips to get started on the Agama Journey.
Tip 1 : Join Agama Lab
While diving into the Agama docs is not a bad idea, Agama Lab gives you a drag-and-drop block programming interface. It’s easy to sign-up using your Github account. Agama Lab does not store any project assets–you must specify a Github repository to store your files. When you “Save” changes on Agama Lab, it makes a commit to the a branch–which you should review and merge according to the standard processes of your domain. Agama Lab is free although there are some in-app purchases available, like the ability to use private Github repositories to store your project assets.
Tip 2 : While your developing the flow, look at the Agama Code
While you are authoring a project in Agama Lab, the “Generate Code” button shows you the Agama DSL equivalent of your blocks. Sometimes missing required fields will be obvious at that point. Or if you’re stuck, it may be a good time to post a question on the Janssen Project Discussions forum.
Tip 3 : Post IDP deployment, use Jans Tarp to test your Agama Project
After you deploy an Agama project to an IDP, you’ll need to test it. Jans Tarp is a browser extension that makes testing a breeze. You can download the test latest Tarp zip file from the Assets section of the Janssen Project Releases. Then just unzip it and load it as an unpacked extension in your browser. Tarp enables you to perform dynamic client registration against your test IDP, and then trigger and authentication flow specifying agama as the acr_values in the OpenID Connect authentication request, and an extra parameter “agama_flow”, which specifies the qualified name of the Agama flow you want to invoke.
For more information about hosting Agama projects at scale, contact the Gluu commercial team or schedule a meeting.