Fiware - How to integrate Keyrock IdM, Wilma PEP Proxy and Orion Context Broker? - fiware

I read all the documentation of Keyrock and Wilma and I watched all the videos in the FIWARE Academy, but I still do not get success in this integration. I am searching for this since a few days ago, but without success. I think the FIWARE documentation could have tutorials, hands on...
I have a VM with Orion Context Broker and a container with Keyrock IdM and Wilma PEP Proxy. I am trying to generate an access token to grant access for an application, but I still did not get it. Besides, I would like to know how can I securely exchange messages between the Orion Context Broker and some IoT devices. Indeed, it is complicated to think about IoT devices having to access a screen and put their credentials to authenticate and to be authorized like the Keyrock IdM examples show. What do you sugest?

Seeing the answer of #albertinisg here, I found a bash script for token request. I changed it to use with my local instances and it worked.
After registering my application at FIWARE Portal (more information here), I had to make a POST request to http://idm:8000/oauth2/token (idm is my local instance of Keyrock). With this valid token, I can access the content in Orion.
import requests, json, getpass
TOKEN_URL = "http://idm:5000/v2.0/tokens"
USER = raw_input("Username: ")
PASSWORD = getpass.getpass("Password: ")
PAYLOAD = "{\"auth\": {\"passwordCredentials\": {\"username\":\""+USER+"\", \"password\":\""+PASSWORD+"\"}}}"
HEADERS = {'content-type': 'application/json'}
RESP = requests.post(TOKEN_URL, data=PAYLOAD, headers=HEADERS)
PEP Proxy (Wilma) configuration (config.js):
config.app_host = 'my_orion_ip'; //change to your Orion address
config.app_port = '1026'; //change to your Orion port
config.username = 'pep_proxy_credential_obtained_at_portal';
config.password = 'password_obtained_at_portal';
With the valid token and the PEP Proxy (Wilma) server running with this configuration, it is possible to control the access to Orion doing a request to PEP Proxy address. The PEP Proxy will redirect this request to IdM (Keyrock) so that IdM can verify the user/device credentials. If the credentials are valid, the user/device will receive a valid token and now PEP Proxy can allow the access to Orion.
For HTTPS communication, I configured a Nginx server to act like a reverse proxy (.conf file):
server {
listen 443;
server_name orion;
ssl on;
ssl_certificate /etc/nginx/ssl/orion.crt;
ssl_certificate_key /etc/nginx/ssl/orion.key;
...
...
location / {
#root orion:1026; #/var/www/yourdomain.com;
#index index.php index.html index.htm;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Fix the “It appears that your reverse proxy set up is broken" error.
proxy_pass http://orion:1026;
proxy_read_timeout 90;
proxy_redirect http://orion:1026 https://orion;
}
}
I made a simple tutorial about the integration of FIWARE Orion, Wilma and Keyrock: https://www.slideshare.net/daltoncezane/integrating-fiware-orion-keyrock-and-wilma
I hope this answer can help someone else.

Regarding Orion, it depends on the interface to be secured, either the service API (i.e. the listening REST server that Orion runs typically at port 1026), the notification API or both:
Regarding service API:
Authentication & authorization: it can be implemented through PEP.
The following documentation introduces two PEP alternative
implementations. However, note that PEP doesn't work standalone, as it
also needs the IDM and Access Control to work. I understand that #Alvaro
can explain this topic in detail (with regards to Wilma PEP). It is out
of my knowledge.
Encryption: it can be implemented by a proxy acting as HTTPS-to-HTTP
bridge (e.g. ngnix) or by Orion itself using the -https CLI
parameter (which works in combination with -key and -cert). This
section of the documentation elaborates on it.
Regarding notification API:
Authentication & authorization: the current implementation of
custom notifications (see "Custom notifications" section in the NGSIv2 specification) allows you to include custom HTTP headers that
could be used for authentication (e.g. the X-Auth-Token header needed
by a PEP instance protecting your endpoint). Note that
this is currently done in an static way, i.e. Orion is not able
to interact directly with IDM/AccessControl to set the X-Auth-Token
value dynamically after expiration, etc. However, it would be possible to develop a
process able to do this and set the proper header (if you are interested
in this I'd recommend to check "How to add a custom header in outgoing notifications with Orion?" post).
Encryption: it can be implemented relaying in Rush component. This
section of the documentation elaborates on it.
UPDATE: since verion 1.7.0, Orion implements native HTTPS notifications (i.e. without needing Rush).

The following presentation shows you step by step how to create a FIWARE-Based IoT Platform and to secure it using a PEP Proxy, Keystone and Keypass.
https://docs.google.com/presentation/d/18LaWZSK4h2wncPF6hNAwK5MToLvJesR3XLrzsqrsmrw/edit?usp=sharing
I hope this helps
thanks

Related

Google cloud compute - forward http to https

I'm on google cloud compute engine with a go webserver (no apache or nginx). I want to forward all http requests to https. My go code has ListenAndServe on port 8080 and the binary runs on port 3000 as https. This was accomplished using below.
gcloud compute forwarding-rules create pgurus --global --address
xxx.xxx.xxx.xxxx --ip-protocol TCP --ports=3000 --target-http-proxy
TARGET_HTTP_PROXY
Thanks in advance!
You can send back a 301 response when you receive an HTTP request. Google Cloud load balancer will set the X-Forwarded-Proto HTTP header with either the value HTTP or HTTPS. See this answer for details:
https://serverfault.com/a/735223
The HTTP response status code 301 Moved Permanently is used for
permanent URL redirection, meaning current links or records using the
URL that the response is received for should be updated. The new URL
should be provided in the Location field included with the response.

Configuring Orion Context Broker, Wilma PEP Proxy and Keyrock IdM

My name is Joe and I'm in traineeship about IoT security and Identity Management. In order to develop some solutions to a project I've been assigned, I have to configure and integrate Orion, Wilma and Keyrock (and potentially a PDP, but that comes later). I've found some tutorials and FIWARE official guides, but I'm seriously in trouble with the configuration.
I've already learned the "theory" behind: I'm aware of the FIWARE security architecture but the problem is on practice.
As a first approach to the problem, I thought that trying to get the token with a token request could be a good way to start, as follows:
curl -X POST --data "grant_type=password&username=user&password=pwd”
http://192.168.100.241:5000/oauth2/token --header
"'Host':'192.168.100.241','Content-Type':'application/x-www-form-urlencoded','Authorization':'Basic
base64(client_id+":"+client_secret)'"
where 192.168.100.241 is the IP address of the host where Keystone runs.
The response to this is the following:
{
"error": {
"message": "Impossibile trovare la risorsa.",
"code": 404,
"title": "Not Found"
} }
Now, how this problems can be solved? Perhaps I'm missing something or probably I'm unaware of something.
And later, how can the PEP Proxy enforce some policies on Orion requests (or receive them directly and later, if allowed, communicate them to Orion)?
Could you help me? I'm terribly in trouble.
Thank you :-)
You can see how to integrate Orion Context Broker, Keyrock IdM and Wilma PEP Proxy in the following link:
https://www.slideshare.net/daltoncezane/integrating-fiware-orion-keyrock-and-wilma
I already had these doubts like you. I hope it helps.
Include client_id and secret_id in the grant_type :
grant_type=password&username=${_user}&password=${_pass}&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}

Fiware AuthZForce error: "AZF domain not created for application"

I'm trying to protect Orion Context Broker using KeyRock idm, Wilma PEP-Proxy and AuthZForce PDP over Docker. For now, level 1 security works well and I can deny access to non logged users, but I get this error on Wilma when trying to add level 2.
AZF domain not created for application <applicationID>
Here it is my azf configuration in Wilma's config.js file:
config.azf = {
enabled: true,
protocol: 'http',
host: 'azfcontainer',
port: 8080,
custom_policy: undefined
};
And this is how I set the access control configuration on KeyRock:
# ACCESS CONTROL GE
ACCESS_CONTROL_URL = 'http://azfcontainer:8080'
ACCESS_CONTROL_MAGIC_KEY = None
I have created the custom policies on Keyrock, but AuthZForce logs don't show any request from KeyRock or Wilma, so no domain is created on the PDP. I have checked that all containers can see and reach each other and that all ports are up. I may be missing some configuration.
These are the versions I'm using:
keyrock=5.4.1
wilma=5.4
autzforce=6.0.0/5.4.1
This question is the same that “AZF domain not created for application” AuthZforce, but my problem persists even with the shown AuthZForce GE Configuration.
I found the cause of this problem that is present when the AuthZForce is not behind a PEP Proxy and therefore the variable ACCESS_CONTROL_MAGIC_KEY is not modified (None by default).
It seems horizon reads both ACCESS_CONTROL_URL and ACCESS_CONTROL_MAGIC_KEY parameters in openstack_dashboard/local/local_settings.py when it needs to connect to AuthZForce. Theoretically, the second parameter is optional (it introduces a 'X-Auth-Token' header for the PEP Proxy), but if horizon detects it is None (the default value in local_settings.py) or an empty string, the log shows a Warning and returns inmediatly from the function "policyset_update" in openstack_dashboard/fiware_api/access_control_ge.py. So the communication to AuthZForce never takes place.
The easier way to solve the problem is to write some text as magic key in: openstack_dashboard/local/local_settings.py:
# ACCESS CONTROL GE
ACCESS_CONTROL_URL = 'http://authzforce_url:port'
ACCESS_CONTROL_MAGIC_KEY = '1234567890' # DO NOT LEAVE None OR EMPTY
Thus, a 'X-Auth-Token' header will be generated, but it shouldn't affect to the communication when the AuthZForce isn't behind a PEP Proxy (the header is simply ignored).
Notice: Remember to delete the cached bytecode file "openstack_dashboard/local/local_settings.pyc" when making changes to assure the new config is updated after restart horizon service.
PS: I sent a pull request to https://github.com/ging/horizon with a simple modification that fixes the problem.

Can anyone explain the usage of Context Broker via PeP proxy?

I have installed orion Context Broker and pep proxy on my machine. I am targeting the global instance of keyRock and the AuthZforce to authenticate the context broker.
Here is my config.js:
var config = {};
config.pep_port = 1307;
// Set this var to undefined if you don't want the server to listen on HTTPS
config.https = {
enabled: false,
cert_file: 'cert/cert.crt',
key_file: 'cert/key.key',
port: 443
};
config.account_host = 'https://account.lab.fiware.org';
config.keystone_host = 'cloud.lab.fiware.org';
config.keystone_port = 4731;
config.app_host = 'localhost';
config.app_port = '1026';
config.username = '<my fiware lab username>';
config.password = '<my fiware lab pass>';
// in seconds
config.chache_time = 300;
// if enabled PEP checks permissions with AuthZForce GE.
// only compatible with oauth2 tokens engine
config.azf = {
enabled: false,
host: 'auth.lab.fiware.org',
port: 6019,
path: '/authzforce/domains/d698df7f-ffd4-11e4-a09d-ed06f24e1e78/pdp'
};
// list of paths that will not check authentication/authorization
// example: ['/public/*', '/static/css/']
config.public_paths = [];
// options: oauth2/keystone
config.tokens_engine = 'oauth2';
config.magic_key = undefined;
module.exports = config;
when I do node server.js
I successfully get:
Starting PEP proxy in port 1307. Keystone authentication ...
Success authenticating PEP proxy. Proxy Auth-token: e2189bdc1a8b4aae9280b0fd5a6ae8a0
following this installation and administration guide I did the following command:
curl --header "X-Auth-Token:e2189bdc1a8b4aae9280b0fd5a6ae8a0" http://localhost:1307
From there I get this message:
[TOKEN] Checking token with IDM...
User access-token not authorized
I am seriously at a loss here and don't know how access context broker via these three intermediaries?
Whose host am I supposed to ask a token from?
I dont know if I am even asking the right questions. The point of all this is to secure an access to context broker.
Edit 1
After setting up the auth-token.sh, I got the following error:
<orionError>
<code>400</code>
<reasonPhrase>Bad Request</reasonPhrase>
<details>service not found</details>
</orionError>
The node server.js reported this:
Starting PEP proxy in port 1307. Keystone authentication ...
Success authenticating PEP proxy. Proxy Auth-token: b90604bc94134c1a81414e97a23196f3
[TOKEN] Checking token with IDM...
[ROOT] Access-token OK. Redirecting to app...
previusly the command: sh auth-token.sh <username> <pass> gave me:
X-Auth-Token for '<my email on fiware lab>': OxFTGtMM6ckBa7FQCUmwvvhj6GQYFc
and then I just curl --header "X-Auth-Token:OxFTGtMM6ckBa7FQCUmwvvhj6GQYFc" http://localhost:1307 which gave me the before mentioned error.
The token shown in the boot screen of the PEP Proxy is not the one you need to authenitcate at the PEP Proxy. Please have a look at the description here: Wilma pep proxy and keystone - valid access token not found.
The easy way is the following:
Download the file provied here: https://raw.githubusercontent.com/Bitergia/fiware-chanchan-docker/master/images/pep-wilma/4.3.0/auth-token.sh
Replace the CLIENT_ID and CLIENT_SECRET with the ones you get from the FIWARE Lab. Also replace https://idm/oauth2/token with https://account.lab.fiware.org/oauth2/token Then just run:
sh auth-token.sh <user-email> <password>
The script will display you the Auth token for the user account you have used. The you can run the following to access the Orion Context Broker:
curl --header "X-Auth-Token: <AUTH-TOKEN-DISPLAYED>" http://localhost:1307
You should now receive a proper response from orion, which should run, based on your configuration, on port 1026.
Make also sure you have configured the the redirect URL in the FIWARE Lab correctly.
The answer given from #geissler is correct. Regarding the Edit 1, this is not an error returned by PEP, Authzforce or KeyRock, is an error regarding Orion Context Broker usage.
Doing
curl --header "X-Auth-Token:OxFTGtMM6ckBa7FQCUmwvvhj6GQYFc" http://localhost:1307
You are not querying any operation, and that's why you receive this error. Please check the Orion User and Programmers Guide to find out how to use Orion Context Broker.
For end to end testing, you can always query Orion just to retrieve the Version by doing:
curl --header "X-Auth-Token:OxFTGtMM6ckBa7FQCUmwvvhj6GQYFc" http://localhost:1307/version
So if you get it, you will properly access the protected Orion.

Configuration Wilma Pep proxy 4.3 - Keyrock 4.3 local instance - IDAS

We have installed a Keyrock instance (Horizon + Keystone) through the automated tools in a local enviroment (Ubuntu 14.0.4 LTS). We have followed this guide
Keystone host: ubuntuHost Keystone port: 5000
Horizon host: ubuntuHost Horizon port: 8000
We have installed a Pep Proxy Wilma in another local enviroment (Centos 6.6):
Pep Proxy Wilma host: centosHost Pep Proxy Wilma port: 80800
We want to configure the Pep Proxy Wilma to attack an instance of IDAS that is installed in the same enviroment that the Pep Proxy Wilma:
IDAS host: centosHost IDAS port: 8080
In order to do this we have put the following configuration file of Pep Proxy Wilma:
config.account_host = 'ubuntuHost:8000';
config.keystone_host = 'ubuntuHost'; config.keystone_port = 5000;
config.app_host = 'centosHost'; config.app_port = '8080';
config.username = 'idm'; config.password = 'idm';
// in seconds config.chache_time = 300;
When we try to run the pep proxy wilma server, the following error shows up:
express deprecated app.configure: Check app.get('env') in an if
statement server.js:35:5 Starting PEP proxy in port 80800. Keystone
authentication ... Error in keystone communication {"error":
{"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
We do not know what is happening here; if this has something to do with the horizon or keystone, or both of them
Could you help us with this?
Thanks in advance,
Rafa.
There can be several reasons why this is failing but I think that most probably is a simple issue where the PEP Proxy user doesn't exists in Keystone or is not properly authorized.
In the configuration file (config.js) of the PEP Proxy you should have two lines like the following:
config.username = 'pepProxy';
config.password = 'pepProxy';
There has to be a user created in the Keystone back-end for the PEP Proxy, the same way OpenStack services like nova or glance have theirs.
If you have used the automated tools, you can create this user and authorize it easily:
$ fab localhost keystone.console
>>> pep = keystone.users.create(name='pepProxy', password='pepProxy', domain='default')
>>> service_role = keystone.roles.find(name='service') # create it if not found
>>> keystone.roles.grant(role=role, user=pep, domain='default')
You can also do this operations using curl directly if you feel more comfortable with it. You can find the REST API documented here Keystone Identity API v3
As I said, there can be other causes why this is happening, please let me know if this answer doesn't fix your issue.