Migration of existing Gluu scripts to Agama?

[ksully-execute]

Any chance there's a migration capability, to take existing scripts from a gluu implementation into an agama flow?

[ksully-execute]

perhaps as easy as allowing code entry in the agama lab flow window (there's an import, but it's expecting json)?
(probably not that simple, but wondering)

[nynymike]

No, we have no plans to do this. 1) You can still use interception scripts in Jans Auth Server... so there is no requirement to migrate. 2) Interception scripts are asynchronous, whereas Agama scripts are sequential.

[ksully-execute]

would you mind expanding on the fact that interception scripts are async and Agama scripts are sequential?
I love the Agama approach, but now am wondering about scalability, if they tie up a thread while the user retries or switches to a different form of authentication (if that's a choice given the script, etc.)?

[ksully-execute]

also, why you're replying, 2 additional questions around this topic:

1. am I missing the documentation on class names, etc. Like in the first tutorial, when it references io.jans.as.server.service.AuthenticationService and io.jans.as.server.service.AuthenticationService
   How would we know these classes exist?
2. I assume that I some docs to translate from some gluu scripts to janssen, with from statements like:
   from javax.faces.context import ExternalContext from org.gluu.model.custom.script.type.user import UserRegistrationType from org.gluu.oxtrust.service import PersonService from org.gluu.service import MailService from org.gluu.service.cdi.util import CdiUtil from org.gluu.util import ArrayHelper, StringHelper

[ksully-execute]

sorry , one more related:
For a more comprehensive Agama based solution, is the intent to call different flows from a controlling flow, or build a big flow with logic to decide which type of authentication is needed, etc.? All the examples are more 'snippet', do you intend to publish a more comprehensive one as an example (maybe mimic current best practice) or is it more of a modular callable thing to build?

[jgomer2001]

Any chance there's a migration capability, to take existing scripts from a gluu implementation into an agama flow?

It's unlikely we could build and offer such tool in the future

perhaps as easy as allowing code entry in the agama lab flow window

They are totally different paradigms. In Agama, flow structure and business logic are separated. In scripts, both things are intertwined

there's an import, but it's expecting json

Import feature is to be able to supply a diagram (a flow chart). If you check your repository, there are json files alongside flow files in the code directory

would you mind expanding on the fact that interception scripts are async and Agama scripts are sequential?

What nynymike actually meant is that control is inverted. In interception scripts you think/design in terms of step 1, step 2, etc., and in the script execution, the respective methods (prepare, authenticate, etc.) are called at every step and passed certain arguments

In Agama, code is executed as in a regular computer program, starting with the first line and advancing to the next, until no more instructions are left - giving a sense of linear execution. In scripts, there is a "controller" logic that decides what methods to call and when. If someone reads a script from top to bottom, there is no way to get a good idea of what's happenning there

if they tie up a thread...

They are not tied to a single thread per user

am I missing the documentation on class names, etc.... How would we know these classes exist?

As in the case of interception scripts, with Agama you have to know of certain classes available in the authentication server classpath. If you already have some experience with scripts in Janssen, you end up using the same classes
You can bundle more classes in your project too. Agama projects support this - that's what the lib folder is for

translate from some gluu scripts to janssen

Gluu (ox*) classes are not the same classes of Janssen but most of times they have the same names and are very similar. They are in the io.jans package and can be found in the Jans repo https://github.com/JanssenProject/jans/

For a more comprehensive Agama based solution...

Modularity and reuse are the most important things that set Agama apart from interception scripts. The way you design is up to you, however there are some good practices to consider: https://docs.jans.io/stable/janssen-server/developer/agama/agama-best-practices/

Because flows look and behave like functions seen in classical imperative programming, you just need to follow the same principles used in everyday coding. Since flow diagrams can take a lot of screen space, you may have to break down stuff more than usual

All the examples are more 'snippet'

The projects in the catalog: https://github.com/orgs/GluuFederation/repositories?q=agama are not really simplistic. Most of them are made up of a flow that calls other flows in turn

is it more of a modular callable thing to build?

That's true. We hope people to reuse those flows in their own projects.

[ksully-execute]

Excellent info, thanks much!