I'm deploying some Generic Enablers(Orion, Cygnus, Proton-Cep, Wirecloud) in the same VM using dockers.
Reading the fiware documentation it uses has an example a wilma proxy securing an instance of orion and getting the authorization through IdM.
Wilma configurations do not seem to support different redirections
I need to secure all these services that I'm using which need to be accessed from outside the server, my question is if is it possible to use Wilma to secure all Generic Enablers or should I implement one instance of Wilma for each service provided?
Related
First of all, I'm using the Telefonica implementations of Identity Manager, Authorization PDP and PEP Proxy, instead of the Fiware reference implementations which are Keyrock, AuthZForce and Wilma PEP Proxy. The source code and reference documentation of each component can be found in the following GitHub repos:
Telefonica keystone-spassword:
GitHub /telefonicaid/fiware-keystone-spassword
Telefonica keypass:
GitHub /telefonicaid/fiware-keypass
Telefonica PEP-Proxy:
GitHub /telefonicaid/fiware-pep-steelskin
Besides, I'm working with my own in-house installation of the components, NO Fi-Lab. In addition to security components, I've an IoT Agent-UL instance and an Orion Context Broker instance.
Starting from that configuration, I've created a domain in keystone (Fiware-Service) and a project inside the domain (Fiware-ServicePath). Then I've one device connected to the platform, sendding data to the IoT Agent behind the PEP Proxy. The whole device message is represented as a single Entity in Orion Context Broker.
So, the question is:
How can I restrict a specific keystone user to access only to the entity associated to this device, at the level of the Orion Context Broker API?
I know that I can allow/deny user acces to specific API via keystone Roles and XACML Policies but that implies that I should create one Policy per User-Device pair.
I could use some help with this, to know if I'm on the right way.
I do not think Access Control can be done to Orion without Security GEs. Each GE has a specific purpose and access control is not one of the Orion's purposes.
As stated in the Security Considerations from Orion documentation:
Orion doesn't provide "native" authentication nor any authorization mechanisms to enforce access control. However, authentication/authorization can be achieved the access control framework provided by FIWARE GEs.
Also, there is something related in another link:
Orion itself has no security. It’s designed to be run behind a proxy server which provides security and access control. Used within the FIWARE Lab, they run another service build on node.js, “PEP Proxy Wilma”, in front of it. Wilma checks that you have obtained a token from the FIWARE lab and put it in the headers.
Besides, the link below can endorse my opinion about Orion and access control:
Fiware-Orion: Access control on a per subscription basis
My opinion is that you are in the right way using the other security components.
About "create one Policy per User-Device pair" as you mention, maybe it would be better you thought about "group policies" instead.
I'm trying to use Wirecloud the latest version available for a simple mashup project. I'm using the ngsi-source operator to retrieve data from Orion, but this is not possible because I often encounter an NGSI Proxy Connection Error (504 Gateway Timeout).
I tried with different installations of the NGSI Proxy in different servers and I have noticed that I have a 200 status in the inner REST calls made by the ngsi-source operator, only when the NGSI Proxy is reachable from the Wirecloud server installation (django server).
When the proxy is reachable only from my browser (local machine), I encounter the 504 status.
The NGSI Proxy has to be reachable from the Wirecloud installation?
Thanks in advance for the answers.
Currently, the NGSI proxy has to be reachable from the WireCloud instance. The url you were seeing (http://<wirecloud domain>/cdp/http/<ngsi-proxy domain>/eventsource) is caused by the use of the Cross Domain Proxy. We developed the NGSI proxy service to allow cross domain requests from browsers and the event source endpoint cannot be used without a direct connection from the client side, so I've opened a ticket in the github repo to solve this bug.
How can we secure the communication between Orion and Cygnus?
How can we use cygnus with a protected Orion (pep is deployed above Orion broker)?
Thanks and best regards.
There are several ways of securing Orion->Cygnus communications:
Co-locate Orion and Cygnus in the same host, so all comunication are through localhost network interface (this solution assumes that the host itslef is properly secured, of course).
Using a firewall (e.g. iptables) so Cygnus port can be reached only from the IP where Orion runs.
Using HTTPS notifications. In order to use this option take into account that:
Cygnus should be able to receive notifications in HTTPS. I'm not fully sure about Cygnus capabilities with this regards, but my colleague #frb could provide more detail.
You need Rush to send notifications in HTTPS with Orion.
You can also explore the posibility of using a PEP proxy for Cygnus. You only need to secure one operation at Cygnus: POST /v1/notifyContext. Have a look to the PEP official documentation.
UPDATE: since verion 1.7.0, Orion implements native HTTPS notifications (i.e. without needing Rush).
I am trying to understand what are really the changes done on Keystone and Horizon forks by GING and are these needed only for the Fiware Lab (i.e. are the Fiware Lab specific)?
We are making our proper Fiware installation for Mainflux IoT Cloud: https://github.com/Mainflux/mainflux, and we are using Orion and IoT Agents. We want to add security layer with Wilma and IDM, and we are wondering if we need Keyrock modifications, or we can use vanilla Keystone and Horizon from OpenStack directly.
Will Wilma work with unchanged Keystone and Horizon from OpenStack?
BR,
Drasko
we've introduce several extensions such us OAuth2, SCIM, user-registration, two factor authentication... We have also modified the UX to fit FIWARE Lab look&feel. And also some administration tools for region management, emails, etc. Wilma will work with vanilla Keystone if you configure it to use keystone tokens. But not with oauth2 tokens.
BR
I'm trying to deploy a Fiware-based system composed by Orion CB and some webapps, and I want to include security in this deployment by using the differents security GE availables.
OrionCB runs on Centos and (i.e)authorization-pdp-authzforce runs on Ubuntu TLS. Does this means that I need to use (i.e)two VPS?
AuthZForce is not supposed to be run on the same machine as Orion Context Broker. This doesn't mean that you can't, only that you are not forced to do it.
What would make more sense to run on the same machine (but still it is not a requirement) is to run a policy enforcement proxy. At the moment there are a couple that work with FIWARE:
FIWARE Wilma PEP Proxy.
FIWARE Orion PEP.
Both of them are developd using NodeJS, so they should run on a CentOS just fine. Keep in mind that even if you use AuthZForce you still need the a PEP proxy.