Skip to main content

Authorization

No action (read model, trigger event, read event log) is allowed unless explicitly allowed. This makes it easy to create a system that is secure-by-design. You declare both positive and negative authorization rules. There must be at least one positive rule that allows the action and there must be no negative rule preventing the action. In this example, the 'Pay' event can only be triggered by the CFO when logged in with multi-factor authentication:

authorization {

readModels {
positive {
rule(::usersCanReadInvoiceItemNames)
rule(::usersInTheFinancialDepartmentCanReadEverything)
}
negative {
}
}

readProperties {
positive {
rule(::everybodyCanReadAllProperties)
}
negative {
}
}

commands {
positive {
rule(::theCFOCanTriggerAnyEvent)
}
negative {
rule(::mustBeAuthenticatedWithMultiFactor)
}
}

eventLog {
positive {
rule(::superadminCanReadEventLog)
}
negative {
}
}

}

As you can see above, you provide Klerk with functions that will be called when the user tries to do something. These functions consider the request and current state and returns a decision. So Klerk uses attribute-based access control (ABAC). If you prefer role-based access control (RBAC) you can easily implement that with a role property on your User model.

If your rule needs information that is not located within Klerk, it is recommended to provide that information in the Context. In this case you would add a field called "isMultiFactorAuthenticated" to the context and use that in the rule. It is also possible to make requests to another system over the network within your rules but be aware that this may severely impact performance.

tip

If you are eager to get started, just put this in your configuration:

authorization {
apply(insecureAllowEverything())
}

This will create rules that allows everything. It will also warn in the log so that you don't forget to change this before you deploy your application.