Agama Keycloak Integration
Agama is a low code block programming solution to build web login flows. In addition to person authentication, developers can use Agama for other "identity orchestration" flows, such as federated discovery, registration, account recovery, assurance level changes and consent.
Agama is governed at the Janssen Project including the following:
- A domain specific language ("DSL") defined here.
- A project archive format ("
.gama") defined here - An Apache 2.0 licensed Java transpiler here.
An IDP that supports Agama would need to have a way to deploy and run .gama archives. Jans Auth Server is where all the development and testing of Agama has been done. Keycloak ("KC") is the obvious next target to expand this capability to a larger community of IDP deployments. So this Agama Keycloak Integration project is an attempt to enable a KC admin to deploy an Agama archive, and then to map OpenID authentication requests to the right Agama flows.
Below is a list of some of the components of an Agama authentication ecosystem:
-
IDP Authentication Component: When a user attempts to authenticate at the IDP, this is the component the IDP hands over the management of the authentication process to. It could be an authentication script , a core authentication management component within the idp itself, or even part of a native authentication flow. -
Agama Core: This is where the bulk of the work for Agama happens. A better name could be the agama engine. It interprets and runs agama flows. -
Agama IDP Driver: This driver is specific to every IDP Agama is to run on. It provides a consistent API that Agama Core leverages to "talk" to the IDP. The idea being for each primitive command or operation (input or output) that Agama Core interprets while running the flow, unless it's an operation it can do internally, it will request the driver to run said operation in a way that is specific to the underlying IDP. The response or access to data from the IDP is also abstracted away by the driver. It basically is an isolation layer between the core and the IDP -
IDP: This is the Identity Provider under which all of this runs.
Also , an authentication flow as a sequence diagram is provided below
- KC Admin UI mockup (Agama Project CRUD, see Jans TUI or Gluu AdminUI for example)
- KC CLI example mockup
- Asset persistence (DB? filesystem? both?)
For Keycloak , pending discussion with the agama team , we're thinking of leveraging
the authenticator feature of Keycloak. But all in all, agama will in some ways substitute itself to the existing browser flow process that already ships with KC.
TBD