Support flows and executions

[alexashley]

This would allow for Terraform to manage arbitrary execution flows that can then override the default flows on either a client or realm-level; the main benefit being that it would allow for custom authenticators to be used to paper over legacy auth solutions or even to require customers to accept new terms and conditions.

API docs:

• flows
• executions

// "basic-flow" is the authentication provider id
keycloak_authentication_basic_flow "custom-terms-flow" { 
      realm_id = "${keycloak_realm.my-realm.id}"
      alias =  "require-new-terms-and-conditions"
      description = "Make customers accept our new T&C"
}

keycloak_authentication_execution "custom-terms-execution" {
       flow_id = "${keycloak_authentication_basic_flow.custom-terms-flow.id}"

       provider = "terms-and-conditions-authenticator"
       config = "?" // this can be an arbitrary map, so maybe it deserves a custom resource
}

[tomrutsaert]

This is something on my todo list, I should be tackling this in the coming weeks

[mrparkers]

I actually started this on the authentication-flows branch.

Unfortunately, I wasn't able to come up with a good way to manage nested flows and executions, which is a use case I have for this particular feature. Keycloak allows you to create top-level flows and subflows, and you can technically have an infinite number of subflows. I couldn't figure out a way to elegantly do this within the provider. I was hoping that v0.12 would have better support for features like this, but I haven't gotten back to this since that update was made.

[tomrutsaert]

I would need this functionality as well. We have a lot of custom authenticators with config and thus also custom flows and executions.
How do you see the way forward?
Could we work with an in-between solution?
How production ready are the changes in your authentication-flows branch?
How can I help?

[tomrutsaert]

@mrparkers, FYI: I will be working on this issue

[tomrutsaert]

The more I look at this, the more I think there should be a separation between topLevelFlows, subFlows and executions.
All 3 behave different in Create/Update/Read/Import and Delete.

[mrparkers]

Thanks @tomrutsaert, I'm glad you have the time to take a look at this.

My branch, as you have probably noticed already, is not quite production ready yet, although the foundation for what you need should be mostly there.

The part I really struggled with was understanding how we can represent subflows in HCL and relate them to the top level flows, or other subflows that are a parent to them. The problem I encountered was that subflows needed to know what flow they are a child of, and the parent flow needed to know about the subflow in order to enforce ordering (to ensure subflow A comes before subflow B for example). This created a bidirectional data flow that I didn't know how to represent in HCL.

The only idea I had that I didn't have a chance to implement was a data source like keycloak_authentication_subflow which has the same attributes as the keycloak_authentication_flow resource, but all the data source does is serialize that model into JSON that can be used in the top level flow. This way, only the keycloak_authentication_flow resource would be controlling its subflows and their order.

I don't know if this will actually work, but feel free to give that a try or pitch some other ideas you might have.

[Pinguwien]

Hey :) Is there any progress on adding flows? Would be a great feature!

[svenstaro]

Can't this be closed now with #138 in?

[tomrutsaert]

Can't this be closed now with #138 in?

Yes, you are right.