Security nodes

From AGILE IoT Wiki
Revision as of 10:27, 12 June 2017 by Dp (talk | contribs)
Jump to: navigation, search

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.

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 =;\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 = \"\";\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"}]


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 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 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