CODEWITHSUNDEEP
fiwarefiware-orionfiware-wilma
hadi gheitasi
hadi gheitasi

Reputation: 5

How can I implement role-based access control for the QuantumLeap microservice in FIWARE?

I'm working with the FIWARE ecosystem and need to secure the QuantumLeap microservice to ensure that only authorized users have access. Specifically, I'm looking to implement role-based access control (RBAC).

What I've Done So Far:

Deployed the Keyrock Identity Manager for user authentication and authorization. Configured the Wilma PEP Proxy to intercept requests to Orion. Defined roles and permissions within Keyrock.

Uncertainty about the best practices for integrating QuantumLeap with Keyrock and Wilma to enforce RBAC. Need clarification on configuring QuantumLeap to recognize and respect the roles and permissions defined in Keyrock.

Could someone provide guidance or examples on how to properly integrate QuantumLeap with Keyrock and Wilma to enforce role-based access control? Any best practices or documentation references would be highly appreciated.

Upvotes: -3

Views: 29

Answers (1)

Jason Fox
Jason Fox

Reputation: 5300

NSGI-v2

Assuming that you are using NGSI-v2, then the incoming data should be intercepted by the PEP/PDP and only accepted roles based data should continue on to the context broker. Therefore a Wilma PEP should be placed between Orion and the outside world - e.g. expose a port for Wilma but don't externally open a port for orion to ensure all data is checked when it arrives.

Data entering quantum leap is via a subscription on the orion. If you really want another PEP you could add an authroization header by adding. a notification.httpCustom.headers.authorization element to the subscription request.

curl -iX POST \
  'http://orion/v2/subscriptions/' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: openiot' \
  -H 'fiware-servicepath: /' \
  -d '{
  "description": "Notify QuantumLeap of count changes of any Motion Sensor",
  "subject": {
    "entities": [
      {
        "idPattern": "Motion.*"
      }
    ],
    "condition": {
      "attrs": [
        "count"
      ]
    }
  },
  "notification": {
    "httpCustom": {
        "headers" : {
            "authorization": "bearer: XXXXXX"
        }
    }
    "http": {
      "url": "http://quantumleap/v2/notify"
    },
    "attrs": [
      "count"
    ],
    "metadata": ["dateCreated", "dateModified"]
  }
}'

Keyrock supports permanent bearer tokens, so you could use that to obtain a token to set in the subscription

curl -X POST \
  http://keyrock/oauth2/token \
  -H 'Accept: application/json' \
  -H 'Authorization: Basic dHV0b3JpYWwtZGNrci1zaXRlLTAwMDAteHByZXNzd2ViYXBwOnR1dG9yaWFsLWRja3Itc2l0ZS0wMDAwLWNsaWVudHNlY3JldA==' \
  -d '[email protected]&password=test&grant_type=password&scope=permanent'

{
    "access_token": "e37aeef5d48c9c1a3d4adf72626a8745918d4355",
    "token_type": "Bearer",
    "scope": ["permanent"]
}

The question is if this second PEP is really necessary - you have already checked access going into Orion so why would you need it again for QuantumLeap? You could keep QuantumLeap deep inside your own infrastructure and not use another PEP. It would only be necessary if you really want to expose the QuantumLeap API, and in that case the containers for Orion, QuantumLeap itself would not be exposed externally, but a proxy for QuantumLeap instead:

e.g. a Wilma with the following variables.

 environment:
   - PEP_PROXY_APP_HOST=quantumleap
   - PEP_PROXY_APP_PORT=8668
   - PEP_PROXY_PORT=8080 # Exposed Port

NSGI-LD

Assuming that you are using NGSI-LD, then quantum leap should not be necessary since you can use the Mintaka extension with Orion-LD to offer the temporal interface. If you use another context broker such as Scorpio or Stellio the temporal interface comes for free.

In this case you can still use the same Wilma PEP on the temporal interface so you'd get RBAC on those endpoints as well.

Further Reading

The following documentation and examples may also help:

Upvotes: 0

Related Questions