Along with the role-based mechanism, it is possible to refine accesses to any specific API or to dynamically compute a specific ACL to be applied to a role.
Resource-based rules are heavily inspired by Amazon IAM rules. The idea is to simply stack a set of rules in a “deny by default” mode and to merge them when necessary to decide “who is allowed to access what in which context”:
- Who is the rule
- Allowed is the rule
Effect: a boolean flag saying
- What is the
Resourceof the rule,
- Context is an optional set of
Conditionsthat can be computed at runtime.
In real-life situation, a rule can have many Subjects, many Resources and many Conditions. Policies are defined by a set of rules. Internally, a dedicated Policy service can be queried by other services to check whether a set of rules, evaluated in a given context, grant Allow or Deny access to the subject.
Again, most policies have a “Deny by default” behavior. For example, when creating a new endpoint in the REST api, it is not accessible (returns 403 Forbidden) until a specific security is added to explicitly provide an access to this endpoint. The engine can also give a precise answer whether the deny response is a DenyByDefault (no rules defined matching this resource) or an explicit deny (e.g. one rule allows access to all, but another rule forbids access to users of a given group). See more examples in following sections.Back to top