APIs in FIWARE should be RESTful APIs. And RESTful APIs in FIWARE should be protected with OAuth2”. This sentence, which is true for most of the enablers in FIWARE, did not completly applied for Cosmos BigData. Until now.

OAuth2 is the evolution of the OAuth protocol, an open standard for authorization. Using OAuth, client applications can access in a secure way certain server resources on behalf of the resource owner, and the best, without sharing their credentials with the service. This works because of a trusted authorization service in charge of emitting some pieces of security information: the access tokens. Once requested, the access token is attached to the service request so that the server may ask the authorization service for the validity of the user requesting the access (authentication) and the availability of the resource itself for this user (authorization).

FIWARE implements the above concept through the Identity Manager GE (Keyrock implementation) and the Access Control (AuthZForce implementation); these two enablers together conform the OAuth2-based authorization service in FIWARE:

• Access tokens are requested to the Identity Manager, which is asked by the final service for authentication purposes once the tokens are received. Please observe by asking this the service not only discover who is the real FIWARE user behind the request, but the service has full certainty the user is who he/she says to be.
• At the same time, the Identity Manager relies on the Access Control for authorization purposes. The access token gives, in addition to the real identity of the user, his/her roles according to the requested resource. The Access Control owns a list of policies regarding who is allowed to access all the resources based on the user roles.

And how does this affects to Cosmos BigData? HDFS (big) data can be accessed through the native WebHDFS RESTful API. This API was not protected with FIWARE authentication/authorization mechanisms but with Hadoop ones. This leaded Cosmos to be one of the few remaining “rebel” enablers avoiding homogeneity in the access to FIWARE APIs.

So, what’s next? Let’s learn with an example!

How can I request an access token? Do the following request to the Cosmos Token Generator in FIWARE Lab (cosmos.lab.fiware.org:13000):

$ curl -X POST "https://cosmos.lab.fiware.org/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=frb@tid.es&password=xxxxxxxx”

{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": “V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"}

As you can see, your FIWARE Lab credentials are required in the payload, in the form of a password-based grant type (this will be the only time you have to give them).

Once the access token is got (in the example above, it is qjHPUcnW6leYAqr3Xw34DWLQlja0Ix), simply add it to the same WebHDFS request you were performing in the past. The token is added by using the X-Auth-Token header:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/to/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix”

{"FileStatuses":{"FileStatus":[...]}}

Now, if you try the above request with a random token the server will return the token is not valid; that’s because you have not authenticated properly:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/tp/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: randomtoken93487345”

User token not authorized

The same way, if using a valid token but trying to access another HDFS userspace, you will get the same answer; that’s because you are not authorized to access any HDFS userspace but the one owned by you:

$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/fgalan/path/tp/the/data?op=liststatus&user.name=fgalan" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"

User token not authorized

Once this point is reached, you may say “OK, but I’m not using WebHDFS at all”. Are you sure? Because, if you are using Cygnus, the tool to build Orion context data archives, then you are using WebHDFS. This is because WebHDFS is the RESTful API used to persist the data in a HDFS backend such as Cosmos. Sadly, any Cygnus version had support for OAuth2… until now. Cygnus 0.8.2 is freshly available and supports OAUth2 through this parameter:

<your_cygnus_agent_name>.sinks.<your_sink_name>.oauth2_token = <your_token>

The token is got from cosmos.lab.fiware.org:13000 as seen before. And upgrading to Cygnus 0.8.2 is as easy as doing:

$ (sudo) yum clean all # just to clean the yum cache

$ (sudo) yum list cygnus# this will show you 0.82 is available

$ (sudo) sudo rpm -e -vv --allmatches --nodeps --noscripts --notriggers cygnus # this is needed if you have installed a version < 0.8.0

$ (sudo) yum install cygnus# this installs 0.8.2

Any doubt? Any question you may have, do not hesitate to contact us through stackoverflow.com or fiware-lab-help@lists.fiware.org. More details can be obtained from these two stack overflow questions:

http://stackoverflow.com/questions/31187977/oauth2-access-to-cosmos-webhdfs-in-fiware-lab

http://stackoverflow.com/questions/31310111/oauth2-in-cygnus