You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
jgomer2001 commented on Nov 26, 2019
In this issue I compile several whishes and ideas I have or have heard from others with respect to improving design and definition of authentication workflows
It has a broader scope than GluuFederation/oxCore#124 so probably we can only start tackling this in 4.2 or 5.x
Leverage a workflow engine/framework that can take charge of running the flows. A Small/manageable one (no big things like BPM)
Flows potentially defined declaratively (ie xml, yaml...) or via GUI
Better UX control in the navigation (eg. safe back button, retaking the point at which the flow was left)
A good level of composability/modularization (eg. reuse of smaller flows to create more complex flows)
Small decoupled chunks of code (no big scripts)
I did a small research in this regard. The only tool I found suitable is Spring Web Flow (actually it may suit very well). However the following is uncertain:
how we can encompass oxauth (Weld) with it
how to provide the flexibility we currently offer (jython scripting to add/edit flows on the fly) because it seems everything needs to be compiled/packaged beforehand. I checked grails framework which is built on top of Spring MVC and originally offered support for spring web flow but the plugin is not maintained anymore. Under Grails is Groovy, a language similar to python which can be used as scripting language in Java. So it might be a solution to evaluate.
Advanced wishlist:
Some form of visualization of flow definitions (or graphical flow edition)
AJAX in html pages, ie not necessarily change page when the flow step changes
Relevant use cases:
Sophisticated identifier-first authentication
Step-up authentication with parametric access policies
A user registration process with credential enrollment
jgomer2001 commented on Nov 30, 2019
I conducted a small investigation on what would be required to implement a flow engine ourselves and concluded the effort is enormous. It's a really cumbersome project.
nynymike commented on Nov 30, 2019
Definitely agree. An enhancement like this should be the result of a formalized product decision. It makes sense to socialize this first.
The text was updated successfully, but these errors were encountered:
jgomer2001 commented on Nov 26, 2019
In this issue I compile several whishes and ideas I have or have heard from others with respect to improving design and definition of authentication workflows
It has a broader scope than
GluuFederation/oxCore#124 so probably we can only start tackling this in 4.2 or 5.x
Leverage a workflow engine/framework that can take charge of running the flows. A Small/manageable one (no big things like BPM)
Flows potentially defined declaratively (ie xml, yaml...) or via GUI
Better UX control in the navigation (eg. safe back button, retaking the point at which the flow was left)
A good level of composability/modularization (eg. reuse of smaller flows to create more complex flows)
Small decoupled chunks of code (no big scripts)
I did a small research in this regard. The only tool I found suitable is Spring Web Flow (actually it may suit very well). However the following is uncertain:
how we can encompass oxauth (Weld) with it
how to provide the flexibility we currently offer (jython scripting to add/edit flows on the fly) because it seems everything needs to be compiled/packaged beforehand. I checked grails framework which is built on top of Spring MVC and originally offered support for spring web flow but the plugin is not maintained anymore. Under Grails is Groovy, a language similar to python which can be used as scripting language in Java. So it might be a solution to evaluate.
Advanced wishlist:
Some form of visualization of flow definitions (or graphical flow edition)
AJAX in html pages, ie not necessarily change page when the flow step changes
Relevant use cases:
Sophisticated identifier-first authentication
Step-up authentication with parametric access policies
A user registration process with credential enrollment
Related issues:
GluuFederation/casa#4
GluuFederation/casa#10
jgomer2001 commented on Nov 30, 2019
I conducted a small investigation on what would be required to implement a flow engine ourselves and concluded the effort is enormous. It's a really cumbersome project.
nynymike commented on Nov 30, 2019
Definitely agree. An enhancement like this should be the result of a formalized product decision. It makes sense to socialize this first.
The text was updated successfully, but these errors were encountered: