|
|
## Introduction
|
|
|
|
|
|
SDK part 1 of the documentation introduced us to the "How to use APIs for Context Manager (Orion) and Time Series (QuantumLeap)".
|
|
|
In those documents we have seen how **anybody** could query **any** type of resources in the platform. That is, as you may imagine, not great in terms of security. \
|
|
|
For demo'ing purposes, we left port `1026` open, so you could query services directly, now, for the production platform that won't be the case, all your requests will need to be authorized, for understanding how to do this we have wrote SDK part 2.
|
|
|
|
|
|
SDK part 2, introduces us to using those same APIs (and others) "securely".
|
|
|
By securely here we mean: the user making the request is authenticated -platform validates who you are-, but also getting authorization for our query -platform validates (or not) the action you want to do-. \
|
|
|
The latter is what is called access control, which in simple words means checking whether you are authorized or not to retrieve, delete or modify a resource (*) of the platform. \
|
|
|
Access controlled is enforced by PEP Proxy (Wilma), this service runs on port `1027`, this is where all your requests are going to be sent to.
|
|
|
|
|
|
(*) resource = FIWARE's entity
|
|
|
|
|
|
## MUST READS
|
|
|
|
|
|
Before getting started with this tutorial, we recommend reading FIWARE tutorial on interacting with IdM (Keyrock) and PEP Proxy (Wilma):
|
|
|
https://fiware-idm.readthedocs.io/en/latest/oauth/oauth_documentation/index.html
|
|
|
|
|
|
If you want to know about how to secure one of your components with PEP Proxy (Wilma) please refer to:
|
|
|
https://fiware-tutorials.readthedocs.io/en/latest/pep-proxy/index.html#logging-in-to-keyrock-using-the-rest-api
|
|
|
|
|
|
## Prepare environment
|
|
|
|
|
|
After cloning the git repo please prepare your environment
|
|
|
|
|
|
```bash
|
|
|
export KEYROCK_HOST=5.53.108.182
|
|
|
export FIWARE_PROXY_HOST=5.53.108.182
|
|
|
cd scripts
|
|
|
```
|
|
|
|
|
|
## User credentials
|
|
|
|
|
|
Each platform client uses credentials (email and password) for authenticating against the identity manager (IdM,)
|
|
|
|
|
|
So at some point you should ask the IdM maintainer (UDGA or SIMAVI) to create credentials for you. If you want to move forward and do that later, that's ok! \
|
|
|
We provide test credentials, but be aware that those are not going to work in production!
|
|
|
|
|
|
|
|
|
## Oauth2 flow and http `Authorization` header
|
|
|
|
|
|
For this demo, we use grant type `password` for the Oauth2 app, this means that the app secret is not private, it is shared in clear text publicly in this repo scripts (Authorization http header). \
|
|
|
This is not very safe, but for demo purposes it should be fine, we may request you to generate this on your own later on. \
|
|
|
If you plan to implement your own app which issues tokens then you should use the standard OAuth2 flows described in the link `MUST READ` section,
|
|
|
|
|
|
The `Authorization` header is `Authorization: Basic NDU3ODhiM2YtMzRjNy00YThlLTkwZGMtZGZiODdlOGFkMGNjOjVmMmI0YTQ5LTJkMDUtNDQ2Ny04NDQ4LTI1ZDA0OWQwMzQ5OQ==`
|
|
|
|
|
|
|
|
|
## Using your credentials to get a token
|
|
|
|
|
|
Please look at the first script created for getting a token with curl:
|
|
|
|
|
|
```bash
|
|
|
>> cat security_01_get_token_with_password.sh
|
|
|
|
|
|
curl -iX POST \
|
|
|
"http://$KEYROCK_HOST:3005/oauth2/token" \
|
|
|
-H 'Accept: application/json' \
|
|
|
-H 'Authorization: Basic NDU3ODhiM2YtMzRjNy00YThlLTkwZGMtZGZiODdlOGFkMGNjOjVmMmI0YTQ5LTJkMDUtNDQ2Ny04NDQ4LTI1ZDA0OWQwMzQ5OQ==' \
|
|
|
-H 'Content-Type: application/x-www-form-urlencoded' \
|
|
|
--data-raw 'grant_type=password&username=test-user@example.com&password=test&scope=permanent'
|
|
|
|
|
|
```
|
|
|
|
|
|
Now, lets try it out using the `development` deployment of keyrock:
|
|
|
|
|
|
```bash
|
|
|
>> ./security_01_get_token_with_password.sh
|
|
|
|
|
|
Querying Identity Managed (Keyrock) at: 5.53.108.182
|
|
|
HTTP/1.1 200 OK
|
|
|
Cache-Control: no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0
|
|
|
Content-Type: application/json; charset=utf-8
|
|
|
Content-Length: 103
|
|
|
ETag: W/"67-ClUkPCX8d82NxI49F/Bx3jRZwN8"
|
|
|
Set-Cookie: session=eyJyZWRpciI6Ii8ifQ==; path=/; expires=Fri, 12 Jun 2020 14:56:17 GMT; httponly
|
|
|
Date: Fri, 12 Jun 2020 13:56:17 GMT
|
|
|
Connection: keep-alive
|
|
|
|
|
|
{"access_token":"b8fb5c456f4cd518b84788e35bbbd2538bf262be","token_type":"Bearer","scope":["permanent"]}
|
|
|
|
|
|
(!) Please export obtained <access_token> as KEYROCK_TOKEN, e.g. 'export KEYROCK_TOKEN=<put_the_received_access_token_here!>'
|
|
|
```
|
|
|
|
|
|
As indicated in the output of this command, you need to export the `access_token` as `KEYROCK_TOKEN`, which will enable you to get resources from the `IoT Platform`.
|
|
|
|
|
|
## Sending request **without** a token, seeing it fail
|
|
|
First, lets see what would happen if we didnt use the token for getting a entity from the context manager:
|
|
|
|
|
|
|
|
|
```bash
|
|
|
>> ./security_02_request_without_token.sh
|
|
|
Querying Fiware entrypoint (PEP_PROXY) at: 5.53.108.182
|
|
|
Auth-token not found in request header%
|
|
|
```
|
|
|
This is normal, this means that the PEP proxy (Wilma) didnt find any authentication information on the request. \
|
|
|
In simple words, this is: "you cannot open the door if you dont have the key"
|
|
|
|
|
|
## Sending request **with** a token
|
|
|
|
|
|
```bash
|
|
|
>> ./security_03_request_with_token.sh
|
|
|
Querying Fiware entrypoint (PEP_PROXY) at: 5.53.108.182
|
|
|
8%
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
## Other issues you may find
|
|
|
/security_03_request_with_token.sh
|
|
|
Querying Fiware entrypoint (PEP_PROXY) at: 5.53.108.182
|
|
|
User not authorized in application%
|
|
|
|
|
|
\ No newline at end of file |