In the current in progress specification of Part 4: Security ARM - Objects a route is defined as follows:
<RouteObject> ::= "ROUTE" <ws> <RouteLiteral> <ws>
<RouteLiteral> ::= <StringLiteral>
There is one note about the asterisk:
Routes may use * or end with a *, which means that all routes with a given prefix are valid.
There are however no examples of the usage besides the all routes case ROUTE "*" and I encountered practical complications while implementing this feature.
Consider the following rule that would be nice to model:
ACCESSRULE:
ATTRIBUTES: CLAIM("org") CLAIM("roles")
RIGHTS: ALL
ACCESS: ALLOW
OBJECTS:
ROUTE "/shells/urn:leisoft:*"
ROUTE "/submodels/urn:leisoft:*"
ROUTE "/shell-descriptors/urn:leisoft:*"
ROUTE "/submodel-descriptors/urn:leisoft:*"
ROUTE "/concept-descriptions/urn:leisoft:*"
FORMULA:
$and(
CLAIM("org") $eq "leisoft",
$regex(CLAIM("roles"), "(^|,)admin($|,)")
)
It grants access to all identifiables belonging to a specific organization to the admins of that same organization. There is an important consideration about encodings however. Should the route segments be encoded as specified in Part 2? Or should it use unencoded values?
ROUTE "/shells/urn:leisoft:*"
Is this correct? Or should it be:
ROUTE "/shells/dXJuOmxlaXNvZnQ6Kg"
?
The first variant is more convenient to model, however it will in many cases break URL rules e.g. if an URL ID is used: https://aas.leisoft.de/*:
ROUTE "/shells/https://aas.leisoft.de/*"
versus
ROUTE "/shells/aHR0cHM6Ly9hYXMubGVpc29mdC5kZS8q"
It would be nice to have this clarified in the specification and an example as well.
For targeting identifiables directly it's also not specified whether the asterisk is allowed. In my opinion it would make even more sense there. The specification already allows this:
In practical scenarios platforms or organizations would grant access rights to a certain organization, group, department or some other hierarchy concept, thus allowing targets such as the following would make access rules much easier to model:
IDENTIFIABLE $aas("urn:leisoft:sales:orders:*")
IDENTIFIABLE $sme("https://iot.leisoft.com/iot-department/sensors/*").sensorValue
However, this seems to be missing in the specs, in particular looking at the explanations in Part 4 - ARM/Objects Clarifying that this is allowed it woud avoid having use ROUTE targets for most cases, but not all which is why the first part of my question remains.
If there is the need to clarify this I would offer myself to open an issue in the security specs and create an appropriate pull request.
In the current in progress specification of Part 4: Security ARM - Objects a route is defined as follows:
There is one note about the asterisk:
There are however no examples of the usage besides the all routes case
ROUTE "*"and I encountered practical complications while implementing this feature.Consider the following rule that would be nice to model:
It grants access to all identifiables belonging to a specific organization to the admins of that same organization. There is an important consideration about encodings however. Should the route segments be encoded as specified in Part 2? Or should it use unencoded values?
Is this correct? Or should it be:
?
The first variant is more convenient to model, however it will in many cases break URL rules e.g. if an URL ID is used: https://aas.leisoft.de/*:
versus
It would be nice to have this clarified in the specification and an example as well.
For targeting identifiables directly it's also not specified whether the asterisk is allowed. In my opinion it would make even more sense there. The specification already allows this:
In practical scenarios platforms or organizations would grant access rights to a certain organization, group, department or some other hierarchy concept, thus allowing targets such as the following would make access rules much easier to model:
However, this seems to be missing in the specs, in particular looking at the explanations in Part 4 - ARM/Objects Clarifying that this is allowed it woud avoid having use ROUTE targets for most cases, but not all which is why the first part of my question remains.
If there is the need to clarify this I would offer myself to open an issue in the security specs and create an appropriate pull request.