Composer REST server

To authenticate clients, we'll need to set up a REST server. With this option available, the clients should be authenticated before they are permitted a call in the REST API.

The REST server uses an open source software named PASSPORT, an authentication middleware for Node.js. It's flexible and modular and supports authentication via username and password, Facebook, Twitter, Google, and Lightweight Directory Access Protocol (LDAP), among others. In Chapter 7, Creating Your Blockchain and IoT Solution, we'll have more details about this. For now, let's review how the components will work.

In the following diagram, we can see a high-level authentication architecture using a Composer REST server:

The following components have been described in the diagram: a frontend application, a composer REST server, LDAP, and Cloudant, a NoSQL database.

If you're working on a test or need to create a proof of concept quickly, I strongly recommend using Facebook, Google, or Twitter for authentication. It'll be easier and faster than other methods.

To use the previous approach to use the composer REST server as custom implementation, we need to do some customization. Perform the following steps:

  1. There's a following line the composer-rest-server installation that needs to be executed before the line:
apk del make gcc g++ python git

Make sure you have a clean environment before using this approach by cleaning all previous installations.

  1. To customize our composer REST server Dockerfile, add the following command in the RUN statements:
su -c "npm install -g passport-ldapauth" - composer && 
  1. Create the following environment variables:
export COMPOSER_CARD=admin@interbancario
export COMPOSER_NAMESPACES=require
export COMPOSER_AUTHENTICATION=true
export COMPOSER_MULTIUSER=true
  1. If you're checking the API call and receive 404, it means you're not logged on:
export COMPOSER_PROVIDERS='{
"ldap": {
"provider": "ldap",
"authScheme": "ldap",
"module": "passport-ldapauth",
"authPath": "/auth/ldap",
"successRedirect": “<redirection URL. will be overwritten by the property 'json: true'>”,
"failureRedirect": "/?success=false",
"session": true,
"json": true,
"LdapAttributeForLogin": “< CHANGE TO LOGIN ATTRIBUTE >",
"LdapAttributeForUsername": "<CHANGE TO USERNAME ATTRIBUTE>",
"server": {
"url": “<URL DO LDAP>",
"bindDN": “<DISTINGUISHED USER NAME FOR A SEARCH>",
"bindCredentials": “<USER PASSWORD FOR A SEARCH>",
"searchBase": “<PATH WITH USERS LIST WILL BE STORED>",
"searchFilter": "(uid={{username}})"
}
}
}'
  1.  Check whether we have an API in our Wallet:
TestValideteLastProcess:A Transaction named TestValideteLastProcess
UpdateOpportunityStatus: A Transaction named UpdateOpportunityStatus
Wallet:Business network cards for the authenticated user

To understand the process authentication better, let's explore this execution flow:

Each API call of composer-rest-server must include access_token, which is brought back by the authentication. For more information, see https://hyperledger.github.io/composer/v0.16/integrating/enabling-rest-authentication.

Some examples using curl are:

curl -v http://localhost:3000/api/system/ping?access_token=xxxxx

Here's another example:

curl -v -H 'X-Access-Token: xxxxx' http://localhost:3000/api/system/ping
  1. This is the final step in setting up your composer-rest-server: creating a business card with Cloudant.

Create member cards with the following attributes:

  • IDwallet-data/admin@system name
  • Key: wallet-data/admin@system name 
  • Value: {"rev" : "5-1af3gs53gwh...."}

Upload the attachment as shown in the following screenshot:

In Chapter 7, Creating Your Blockchain and IoT Solution, we'll deploy this implementation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.165.246