Difference between revisions of "Security nodes"

From AGILE IoT Wiki
Jump to: navigation, search
m
(Example to get Github Repositories of the user logged in)
Line 4: Line 4:
  
 
This example uses the idm-token node to obtain the token from the session and query github to find out the names of all the repositories owned by the user logged in through the agile OS.js framework.  
 
This example uses the idm-token node to obtain the token from the session and query github to find out the names of all the repositories owned by the user logged in through the agile OS.js framework.  
 +
The prerequisites for this example are:
 +
* Node.js
 +
* Github accout
 +
* AGILE Gateway
  
 
=== Set-up ===
 
=== Set-up ===
Line 68: Line 72:
 
* function node: this function node parses the result from github and creates an array of the repository names.
 
* function node: this function node parses the result from github and creates an array of the repository names.
 
* debug: prints msg.payload in the debug tab
 
* debug: prints msg.payload in the debug tab
 
  
 
== Example to get user's role from AGILE IDM ==
 
== Example to get user's role from AGILE IDM ==

Revision as of 12:28, 12 June 2017


Example to get Github Repositories of the user logged in

This example uses the idm-token node to obtain the token from the session and query github to find out the names of all the repositories owned by the user logged in through the agile OS.js framework. The prerequisites for this example are:

  • Node.js
  • Github accout
  • AGILE Gateway

Set-up

This example requires some setup. If you want to get started without any set-up check the next example

Oauth2 github setup

Given that this example uses github, you should first configure the Oauth2 client id and secret in AGILE IDM. For this, update the configuration file in $DATA/idm/conf/ (based on the $DATA env variable in your docker-compose file in the agile-stack) following the steps described in AGILE IDM's documentation https://github.com/Agile-IoT/agile-idm-web-ui/blob/master/docs/idps-configuration.md. Once this is finished, you should register your github username with IDM, so that IDM lets you access the gateway when log in with this particular github account.

Create Github user in IDM

Take the following script:

 var token = "TdrlBIJTtHRr8c3kjj45YpnmP1cVdpizsIqDD6xdFq1QVkHWKtaj2dQYh0Tt8Ss7";
 var user = "your-github-user";
 var api = 'http://agilegw.local:8080';
 var idmurl = 'http://agilegw.local:3000';
 var agile = require('agile-sdk')({
  api: api,
  idm: idmurl,
  token: token
 });
 
 agile.idm.user.create(user,"github",{"role":"admin"})
 .then(function(entity){
   console.log('user  created !'+JSON.stringify(entity))
   return agile.idm.user.get(entity.user_name, entity.auth_type);
 }).catch(function(err) {
   console.log(err)
 });

and follow these steps:

  • Install agile-sdk with npm (npm install agile-sdk)
  • update the token (by checking the token in the URL after you log in with OS.js with any admin user, i.e. agile user
  • place your github username in the user variable.
  • save the script and execute it with node script_name.js
  • once the action has been executed you should see: "user created !{"auth_type":"github","user_name":"github_user","role":"admin","id":"github_user!@!github","type":"/user","owner":"github_user!@!github"}"

Deploy the flow

To deploy the example import the following flow in your AGILE-NodeRED application with the functionality Import-> from Clipboard:

 [{"id":"40f22e2b.3b0048","type":"inject","z":"1a8e97e1.9f0e2","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":290,"y":83,"wires":"fa1ed603.093dc"},{"id":"b64946ab.2a69","type":"function","z":"1a8e97e1.9f0e2","name":"prepare-github","func":"msg.url = \"https://api.github.com/user/repos\";\nmsg.headers = {\n    \"Authorization\": \"bearer \"+msg.token,\n    \"User-Agent\" :\"nodejs\"\n};\nmsg.method = \"GET\"\n\nreturn msg;","outputs":1,"noerr":0,"x":360,"y":198,"wires":"8063aef1.e619b"},{"id":"8063aef1.e619b","type":"http request","z":"1a8e97e1.9f0e2","name":"","method":"GET","ret":"txt","url":"https://api.github.com/user/repos","tls":"","x":398,"y":258,"wires":"389aad64.751f12"},{"id":"ccc2ba69.05fe78","type":"debug","z":"1a8e97e1.9f0e2","name":"","active":true,"console":"false","complete":"false","x":506,"y":349,"wires":[]},{"id":"fa1ed603.093dc","type":"idm-token","z":"1a8e97e1.9f0e2","name":"","tokensource":"session","idm":"http://agile-idm:3000","userinfo":false,"x":348,"y":131,"wires":"b64946ab.2a69"},{"id":"389aad64.751f12","type":"function","z":"1a8e97e1.9f0e2","name":"","func":"var ob = JSON.parse(msg.payload);\nvar r = [];\n//get the name for every repository\nob.forEach(function(v){\n    r.push(v.name);\n})\nmsg.payload = r;\nreturn msg;","outputs":1,"noerr":0,"x":500,"y":298,"wires":"ccc2ba69.05fe78"}]

Result

You should now see the the following flow in your Node-RED.

Simple-github-flow.png

From now on, if you log-in with github as authentication type, with the user you have created, you should be able to see your repositories in node-red.

Understanding the example

  • timestamp: This node is there to trigger the flow (it can be replaced by a device node, an http, websocket input, etc).
  • idm-token: This node obtains the token information for the user currently logged in with OS.js (that is to say, your github user). If you double click on this node, there will be some information available. The token source represents the location chosen by the node to pick up the token. In this example, we use the session (OS.js and Node-red logged in user). However, if you use http header instead, you should be able to obtain the token (if you pass it in the authorization header with the bearer format).
  • prepare-github: this function node prepares the request to send it to github. To do this, it sets the msg.url to point to the API endpoint querying the user's repos, i.e. "https://api.github.com/user/repos, sets the authorization header required by github by placing the token obtained through the idm-token node and sets the request type as GET.
  • http-request: just sends the http request as specified by the arguments
  • function node: this function node parses the result from github and creates an array of the repository names.
  • debug: prints msg.payload in the debug tab

Example to get user's role from AGILE IDM

IDM lets you obtain entity's attributes from any entity (provided that security policies allow you to read the information). In this particular example, we will show how a simple flow can be constructed so that the role of the currently logged in (through AGILE's UI) can be obtained. To this end, we use the idm-token as well as the entity attribute node.

Deploying the Flow

To deploy the example import the following flow in your AGILE-NodeRED application with the functionality Import-> from Clipboard:

 [{"id":"86c2266b.ee8708","type":"idm-token","z":"9d49616.e87232","name":"","tokensource":"session","idm":"http://agile-idm:3000","userinfo":true,"x":205,"y":176,"wires":"b87fee1c.09ce8"},{"id":"b87fee1c.09ce8","type":"function","z":"9d49616.e87232","name":"set-attribute-args","func":"msg.entity_id = msg.userInfo.id;\nmsg.entity_type = \"user\";\n//they can point to nested properties or not, e.g. just credentials also works.\n//msg.attribute = \"user_name\";\nmsg.attribute = \"role\";\n//if this is not there, message will contain the property in msg.entity_attribute\nmsg.payload = {\"title\": \"Your Role is\"};\n//they can point to nested properties or not, e.g. just my_credentials also works but it overrides the whole object\nmsg.destination_property = \"payload.info\";\n\n\nreturn msg;","outputs":1,"noerr":0,"x":383,"y":120,"wires":"7de23f7e.fa2798"},{"id":"7de23f7e.fa2798","type":"idm-attribute","z":"9d49616.e87232","name":"","idm":"http://agile-idm:3000","x":437,"y":179,"wires":"eaf73a2c.6b542"},{"id":"c19ea360.93d54","type":"inject","z":"9d49616.e87232","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":156,"y":81,"wires":"86c2266b.ee8708"},{"id":"7b17116f.3154c","type":"debug","z":"9d49616.e87232","name":"","active":true,"console":"false","complete":"payload","x":608,"y":86,"wires":[]},{"id":"eaf73a2c.6b542","type":"json","z":"9d49616.e87232","name":"","x":592,"y":178,"wires":"7b17116f.3154c"}]

Result

In the end, you should be able to click on the inject node and see in the palette how the role with some additional text appears in the debug tab. Simple-role-example.png

Understanding the Example

We will go node by node, explaining their responsibilities in the flow:

  • timestamp: This node is there to trigger the flow (it can be replaced by a device node, an http, websocket input, etc).
  • idm-token: This node obtains the token information for the user currently logged in with OS.js. If you double click on this node, there will be some information available. The token source represents the location chosen by the node to pick up the token. In this example, we use the session (OS.js and Node-red logged in user). However, if you use http header instead, you should be able to obtain the token (if you pass it in the authorization header with the bearer format). Also, this node has a checked box termed user info. This instructs the node to bring the user id and authentication type and place them in the message (This will be used later in the flow).
  • set-attribute-args: is a function node that prepares the arguments required by the attribute node. If you check the source code of this function node, you will see that the values msg.entity_id, and msg.entity_type, msg.attribute and msg.destination_property are placed in the message. These arguments specify the information required by the flow. In particular the entity_id value is set to msg.userInfo.id. This value is placed in the message by the idm-token node (because we have checked the user info box) and contains the id of the user who is currently logged in. The msg.entity_type is user and msg.attribute contains role. Nonetheless, this value can contain any attribute type that is defined for the user. Last but not least, the msg.destination_property lets the attribute node know where to place the attribute obtained from IDM. In this case it is placed inside payload.info. This argument is optional. For information on default values see the info tab on node-red for each node. Also, in addition to the message properties mentioned below the attribute node requires that the msg.token property contains a user's token; however, this has been already solved by the idm-token node.
  • json: parses the object and converts it to a string
  • debug: prints msg.payload in the debug tab