Access Controls and Policies
Attribute names can be used to define policies and policies can be used to define access controls:
Policies are expressions involving attribute names, which can be evaluated to
trueorfalsegiven an environment containing attribute values.Access controls were discussed earlier. They restrict the messages which can be received or sent by a worker.
Policies
Policies are boolean expressions constructed using attribute names. For example:
In the expression above:
and,=,member?are operators.resource.version,subject.name,resource.adminsare identifiers.1,"John"are values.
Values can have the 5 following types:
StringIntFloatBoolSeq: a sequence of values
This table lists all the available operators:
and
>= 2
Produce the logical conjunction of n expressions
or
>= 2
Produce the logical disjunction of n expressions
not
1
Produce the negation of an expression
if
3
Evaluate the first expression to select either the second expression or the third one
<
2
Return true if the first value is less than the second one
>
2
Return true if the second value is less than the first one
=
2
Return true if the two values are equal
!=
2
Return true if the two values are different
member?
2
Return true if the first value is present in the second expression, which must be a sequence Seq of values
exists?
>= 1
Return true if all the expressions are identifiers with values present in the environment
Examples
Here are a few more examples of policies.
The subject must have a
componentattribute with a value that is eitherwebordatabase:
Note that attribute names can have dots in their name, so you could also write:
You can also declare more complex logical expressions, by nesting and and or operators:
The subject must either by the "Smart Factory" application or being a member of the "Field Engineering" department in San Francisco:
Boolean policies
Since many policies are just need to test for the presence of an attribute, we provide simpler ways to write them.
For example we can write:
Simply as (note that logical operators can now be written as infix operators):
String comparisons are still supported, so you could also have a component attribute and write:
More complex expressions require parentheses:
Since identities are frequently used in policies, we provide a shortcut for them. For example, this is a valid boolean policy:
It translates to:
This table summarizes the elements you can use in a simple boolean policy:
name
Equivalent to (= subject.name "true")
name="string value"
Equivalent to (= subject.name "string value")
and
Conjunction of 2 expressions
or
Disjunction of 2 expressions
not
Negation of an expression
identifier
Equivalent to (= subject.identifier "identifier")
()
Parentheses. Used to group expressions. The precedence rules are not > and > or
Evaluation
We evaluate a policy by doing the following:
Each attribute
attribute_name/attribute_valueis added to the environment as an identifiersubject.attribute_nameassociated to the valueattribute_value(always as aString). In the example of a policy given above the identifiersubject.namemeans that we are expecting an attributenameassociated to the identity which sent a message.The top-level expression of the policy is recursively evaluated by evaluating each operator and taking values from the environment when an expression is referencing an identifier.
The end result of a policy evaluation is simply a boolean saying if the policy succeeded or not.
Access controls
The library offers two types of access controls using policies:
AbacAccessControl.PolicyAccessControl.
AbacAccessControl
AbacAccessControlThis access control type is used as an IncomingAccessControl (so it restricts incoming messages).
We define an AbacAccessControl with the following:
A
Policywhich specifies which attributes are required for a given identity.An
IdentityRepositorywhich stores a list of the known authenticated attributes for a given identity.
When a LocalMessage arrives to a worker using such an incoming access control, we do the following:
If an identity is not associated to this message (as
LocalInfo), the message is rejected.Otherwise the attributes for this identity are retrieved from the repository.
The attributes are used to populate the policy environment.
The policy expression is evaluated. If it returns
truethe message is accepted.
PolicyAccessControl
PolicyAccessControlThis access control type is used as an IncomingAccessControl (so it restricts incoming messages).
We define a PolicyAccessControl with the following:
A
PolicyRepositorywhich stores a list of policies.A
Resourceand anAction. They represent the access which we want to restrict.An
IdentityRepositorywhich stores a list of the known authenticated attributes for a given identity.
When a LocalMessage arrives to a worker using this type of incoming access control, we do the following:
If an identity is not associated to this message (as
LocalInfo), the message is rejected.Otherwise the attributes for this identity are retrieved from the repository.
The most recent policy for the resource and the action is retrieved from the policy repository.
The attributes are used to populate the policy environment.
The policy expression is evaluated. If it returns
truethe message is accepted.
The two major differences between this policy and the previous one are:
The
PolicyAccessControlmodels aResource/Actionpair.Policies for that resource and action can be modified even if the worker they are attached to is already started.
Last updated
Was this helpful?