I'm using the Apached C++ QPID broker and it's failing to parse this rule:
acl deny-log all all broker. Tokens found after action "all"
I'm trying to prevent anyone from modifying the broker.
It turns out the C++ broker doesn't allow anything after acl <permission> all all. Brokers only have access and update permissions. The fix was to add:
acl deny-log all access broker
acl deny-log all update broker
Related
I have in my server a Orion Context Broker (https://github.com/telefonicaid/fiware-orion) but i need to add some restrictions to my "consumers" when they use the endpoint(s) e.g(http://myhost:1026/v2/entities). Is possible configure the local/personal Broker with token like https://fiware-orion.readthedocs.io/en/1.11.0/quick_start_guide/index.html#orion-context-broker-quick-start-guide ?
Thank you very much.
The Orion Context Broker does not offer roles and permissions directly.
To add roles and permissions to restrict an endpoint, you will need to use a PEP Proxy - which security mechanism you use to do this is up to you.
There are several OAuth2-based security components found within the FIWARE Catalogue, alternatively you could another open source PEP Proxy such as steelskin which integrates nicely with either Keyrock or Keystone
Despite of set attrsFormtat to legacy it's not working, I get Missing parameter: updateAction
Any suggestions?
Thanks.
EDITED: I try it in a million ways and i can't handle this always getting the same error.
I am not an expert in Cepheus Broker but I have a bit of experience playing with Cepheus CEP and Orion Context Broker in FIWARE ecosystem, maybe I can be useful.
According to the official documentation of CEP, you should be deploying Cepheus Broker before Orion Context Broker instead after. I know that both speak the same NGSI API so it should be the same, but I am not completely sure about that. Any particular reason why you are deploying these components in that order?
I make a little experiment using official Docker images of Cepheus Broker and Orion context Broker, creating context subscriptions through v1 and v2 Orion APIs. The same error as you on Cepheus Broker logs.
Then I proved with this little app made by Fiware fellows, that you can use for debbuging NGSI context subscriptions. I tried with v1 and v2 subscriptions, with legacy and no legacy in v2 and any of this produces a "updateAction" field in the request. Then I realized that as far as I know, within the NGSI API methods the only service that receives the updateAction parameter is the updateContext service.
May be Cepheus can not connect with Orion Context Broker through Context Subscription mechanism. Maybe he's waiting for a context update instead a context change notification.
Sorry for not being of more help.
Regards!
You are trying to make Orion send a notifyContext request to the updateContext endpoint of Cepheus CEP. This cannot work as an updateContext request is expected to contain an updateAction field in the payload according to the NGSI v1 protocol.
Cepheus CEP expects notifications from subscriptions to be done to its notifyContext endpoint.
Moreover Cepheus CEP will send its own subscription requests to Orion when properly setup (you must declare Orion as a provider in the CEP configuration). It will ask Orion to send back notification to the correct endpoint.
Finaly, you cannot make the subscription on behalf of Cepheus CEP like you are trying to do: Cepheus CEP will only accepts notifications for the subscriptions it made itself because it validates the subscription ids of all notification it receives.
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.
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've spent most of the day trying to configure the Fiware PEP proxy Wilma to secure an Orion Context Broker i have running on a development server. The documentation here: http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/PEP_Proxy_-Wilma-_Installation_and_Administration_Guide is not clear.
Here is my setup:
A Fiware Keyrock instance running on server1, port 3000
A PEP Proxy running on server 1
An Orion Context Broker running on server2, port 1026
The manual states to edit the config.js script. Here is what i changed (Stackoverflow prevents me from entering url's so replace http.. with http:)
config.account_host = 'http..//localhost:3000';
config.keystone_host = 'http..//server1';
config.keystone_port = 3000;
config.app_host = 'server2';
config.app_port = '1026';
config.username = '***** username of the user in Keyrock *****';
config.password = '***** password of the user in Keyrock *****';
Here is the error
~/fi-ware-pep-proxy$ node server.js
express deprecated app.configure:
Check app.get('env') in an if statement server.js:30:5 Starting PEP proxy. Keystone authentication ... Error in keystone communication
Error: getaddrinfo ENOTFOUND
at errnoException (dns.js:37:11)
at Object.onanswer [as oncomplete] (dns.js:124:16)
My Orion and Keyrock instances are up and running. I can query them with curl or a browser.
I really have no idea what i should be filling in the config.js to get this set up.
I hope this helps. We are working on deploying some of the Generic Enablers, included IdM, Wilma PEP and Orion among others using docker and docker-compose.
This environment, called Fiware-devguide-APP is actually under construction, but you can test's the environment (already working) and also check our configuration here.
We are updating all the documentation!
For this, we have the images here.
Docker and docker-compose are required.
If you already have them, to start all the apps integrated in Devguide, you just have to clone the repository:
git clone https://github.com/Bitergia/fiware-devguide-app.git
And then run docker-compose using the .yml file in the fiware-devguide-app/docker/compose:
docker-compose -f docker-compose.yml up -d
So you will have up all the containers! Finally, add the ip of the devguide container (compose_devguide_1) to your /etc/hosts and you will be able to browse it :)
Explanation:
We've went through several configurations for this. I assume you are interested in IdM and Wilma PEP, so here it goes what we did:
We've installed a IdM GE from the scratch providing the users, roles, and permissions desired. Here you can find what we added at test_data method:
We've added test users
Couple organizations
Our app
Roles for the application
And permissions for the actions
Note that all those provision could have been done also using Keystone REST API
Also here you can find the Dockerfile i.e. how it has been installed.
We've installed an Authzforce for the role management as explained in the tour guide. You will need it as wilma-pep will send the PDP requests to validate requests against the resource protected.
Finally the PEP Wilma. Here you can find the configuration files.
How does it work?
Here goes the trick. Let's assume the env Authzforce (Access Control), IdM, PEP Wilma, Orion (the app to be protected) and the devguide. As we use docker-compose, all this steps are done almost at the same time! :)
In authzforce, we need to create a domain as stands in the documentation, and we do it here.
The script itself retrieves the domain ID and, it parses the config.js file of the PEP Wilma in this line using the right path.
The config.js is simple:
account_host and keystone_host are in the same container 'idm'. Docker-compose handle this by adding aliases to the /etc/hosts of each container, which makes the process much easier and we don't need to handle the IP's ourselves.
app_host and app_port are the IP and port of the app to protect, in our case is 'orion'!
config.username and config.password. We've created a user 'pepproxy' in the provision we explained before, exactly here. (Note that this user must have domain roles assigned in order to work, as done here).
And the azf configuration, which contains also the 'authzforce' host and where the path is parsed as explained before.
Adding the authzforce configuration to IdM and PEP (i.e. domain)
Get an Oauth2 token as it explains here.
Finally, with this token and everything running, you can open the compose_devguide_1. It has different resources that can be reached depending on the roles you have assigned at IdM. For example, 'user0#test.com' can access to all the resources, meanwhile the other one can access just to the restaurants.
Hope I was clear enough.
Best!
right now requests from PEPs are not directly sent to the IdM. They uses an Openstack compliant server (Keystone Proxy). So if you want to use it you have to install also this component. Any way in two weeks we are going to change this behaviour.
Hope this helps
We are installing a Fiware enviroment in a local machine; we pretend to have an orion context broker with a Keyrock idm instance. We understand that we need to use a Pep Proxy in order to check the tokens of the requests to the orion context broker. We use Keyrock idm, so we are wondering whether we can do this or not. Is there any way to use them now without installing anything else or we are supposed to install de keystone proxy too?
This is the keystone proxy that we have found:
https://github.com/ging/fi-ware-keystone-proxy
If this is the case; How do we have to configure the pep proxy? Where do we have to put the data to connect to the Keyrock idm and where are we supposed to indicate the keystone information?
new versions are ready. Now you only need Keyrock and PEP Proxy. As explained here validations go directly to IdM. Hope this helps.