FIWARE Orion-LD access control rules by entity type

Question

Is it possible to configure access-control rules for Orion-LD based on the entity type? Or, alternatively, on the presence of some attributes in the entities?

A similar question was asked here: Get a list of all resources accessible to users in FIWARE. The answer seems to imply that in the so-called Advanced Authorization scenario it is possible to achieve something like this by means of XACML filters for broker endpoints, allowing for instance GET access to the endpoint /entities?type=SomeEntityType for certain users. However, this appears like a very brittle solution, since the type query parameter may be preceded by other params in a real-world request. Furthermore, there are other ways to filter resources returned by the /entities endpoint, e.g. by means of parameters q or attrs (according to the NGSI-LD spec, https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.06.01_60/gs_CIM009v010601p.pdf, see 6.4.3.2), hence separate rules would be needed for all of these and it seems impossible to keep them consistent. Ideally, I would also like GET requests to /entites/{entityId} to be evaluated against the type of the entity, without configuring this individually for every entity.

Am I missing a simple solution to this problem?

[Clarification addded] To clarify, my intention is to define a single policy, symbolically something like

allow { entityType: SomeType, action: READ, role: SomeRole }

and the goal is to apply it all GET requests to the /entities endpoint, in particular to

• list entity requests with type filter: /entities?type=TypeA
• list entity requests with attributes filter: /entities?attrs=attributeA
• list entity requests with arbitrary query filter: /entities?q=speed>50;brandName!="Mercedes"
• individual entity requests: /entities/urn:ngsi-ld:TypeA1

In the absence of other policies I'd expect the results of the first three requests to return the query results filtered by entities of type SomeType, as specified in the policy, and the last one to succeed if any only if the type of the entity is SomeType. But it seems that this is not possible. Instead, I'd have to define additional policies, e.g.

allow { attributes: ["attr1", ..., "attrn"], action: READ, role: SomeRole }
allow { entity: "urn:ngsi-ld:SomeType*", action: READ, role: SomeRole }

Furthermore, the PEP would need to extract the values of the query parameters attrs, type, etc. and forward them to the PDP. However, the generic query /entities?q=... will be hard to deal with, the attributes permission will enable access to other entity types with the same attributes, and the naming convention for entities to start with the type name must be strictly followed. All these caveats seem to imply that the scenario is not really supported.

Answer 1

This will depend on the capabilities of the PDP you are using. Of course, a flexible XACML-based PDP like Authzforce is able to adjudicate on anything given sufficient information from the PEP, but you could also use something like Open Policy Agent it is just the matter of extracting sufficient information from the payload and passing it on for analysis.

To take the Keyrock/Wilma as an example, they support a payload-based PDP permit/deny decision process. In Keyrock you have 3 different PDP levels - basic, payload and advanced. If you set - IDM_PDP_LEVEL=payload, you can set permissions like this:

Where the type, id and attrs in the payload can be filtered.

Keyrock's basic /user?access_token=..&action=..&resource=.. PDP only covers basic rules, so to check payloads you'll need to switch to use a more advanced PDP. Keyrock's /pdp/xacml handler accepts XACML JSON from a PEP, so Wilma can be configured to use that endpoint instead.

PEP_PROXY_PDP=xacml 
PEP_PROXY_PDP_PROTOCOL=https               
PEP_PROXY_PDP_HOST=<hostname_of_keyrock>            
PEP_PROXY_PDP_PORT=<port of keyrock>              
PEP_PROXY_PDP_PATH=pdp/xacml

Of course this is just an example, the PDP could just as easily be pointed towards Authzforce for adjudication and send over XACML XML. The point is that whichever PDP you decide to use, the PEP needs to be able to extract the right info and pass on a request to your chosen PDP.

Note that resource can also take a regex (if the regular expression checkbox is ticked) so allowing the following:

• /entities?type=TypeA
• /entities?type=TypeA&attrs=att1,att2
• /entities?type=TypeA&q=speed>50;brandName!="Mercedes"

Could be achieved by the regex /\/entities\?type=\w+($|.*)/

According to the NGSI-LD 1.6.1 Specifications:

At least one among: type, attrs, q, or georel shall be present.

But in your case you'll always want to filter on type so it is best to make it mandatory and disallow: /entities?q=speed>50;brandName!="Mercedes".

/entities/urn:ngsi-ld:TypeA1 is a different endpoint to all the others, and is more easily restricted using a separate rule.