Get a list of all resources accessible to users in FIWARE

Question

I would like to adopt FIWARE as part of our IoT platform. In addition to Orion Context Broker, I would like to use keyrock / wilma / AuthzForce for authentication and authorization.

I understood by reading "step-by-step" and other documents that there are multiple users on the IoT platform and it is possible to control access to resources individually.

I would like to display a list of all resources (It's equal to the sensors) that the user can access after logging in our IoT application. However, I referred to the keyrock and AuthzForce APIs, but I don't think there is such an API. Isn't there an API in FIWARE that gets a list of user-resource (sensor) relationships?

Answer 1

FIWARE is not tightly bound to a single security stack. The "step-by-step" tutorials are using Keyrock and Wilma as an illustrative example, but you could just as easily use alternative Identity Managers such as Keycloak or Keystone - it is the role of the IDM which is important.

Given that every component in the FIWARE Catalogue is a microservice they are designed to do one job well rather than mixing concerns, so you would need the following set up - keep the roles and permissions in the IDM, add static data to your entities to describe what the entities are and who "owns" them.

Basic Authentication

For basic authentication where every logged in user is able to view your sensors this is easy:

• The IDM holds the users, roles and permissions.
• The Devices are configured by an IoT Agent - this creates entities in the context broker. Use a static attribute e.g. sensor to allow for easy of querying (the Device Model suggests category:

"static_attributes": [
    {"name": "category", "type":"Text", "value": ["sensor"]}
]

This will enable clients to make queries on /entities?q=category=="sensor"&type=Device to get all Device in the sensor category.

if all logged-in users can access all sensors you can just place a PEP proxy in front of the context broker which denies all unauthenticated requests (i.e. those without a bearer token) and passes through those that are logged in.

Basic Authorization

For basic authorization where logged in user is able to view the sensors they own it's a bit more complex, you'll need to set up permissions to allow a role to access: /entities?q=category=="sensor"&type=Device&owner==XXX whilst denying broader queries like /entities?type=device - you can then add additional static data to the devices when provisioning:

"static_attributes": [
    {"name": "category", "type":"Text", "value": ["sensor"]}
    {"name": "owner", "type":"Text", "value": "XXX"}
]

Advanced Authorization

For advanced authorization it would be even more complex, your Authzforce PDP would need to hold rules like:

<Rule RuleId="xxxxx-xxxx-0000-0000-000000000000" Effect="Permit">
  <Description>Query Devices</Description>
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:3.0:function:string-equals">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/entities?q=category=="sensor"&type=Device&owner==XXX</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Condition>
    <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
      <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">security-role-0000-0000-000000000000</AttributeValue>
      <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false" />
    </Apply>
  </Condition>
</Rule>

Where users of the role security-role-0000-0000-000000000000 are allowed to make the GET request to devices as described above.

With XACML it would be possible to extend the rules using functions like urn:oasis:names:tc:xacml:1.0:function:string-regexp-match or urn:oasis:names:tc:xacml:1.0:function:string-regexp-match, but you should look at finding an XACML GUI editor, the XACML 3.0 spec is easier for machines than humans. By default the Wilma PEP proxy passes over sufficient information for Authzforce to answer the rule defined above, if you want add more clauses to the matching rule, you will need to customize the PEP-PDP comms within your PEP Proxy to ensure additional information is sent to Authzforce to allow it to adjudicate the request.