Hello Suresh, The SDK is not complete and I was only able to code certain aspects of it, and sorry If I have not mentioned it clearly.
1) Writing the Curl functions to hit the endpoint to get the tokens 2) Building an authorization flow and credential store from the secret json file. I believe the above steps and the endpoints can be modified to suit for Airavata use. The document which I submitted serves as an analysis on my research and develpment on that front, and serve as a start point upon which this SDK can be further built to run it for Airavata. If there is anything else I can do, please let me know. Thanks, Vasanth On Thu, Apr 26, 2018 at 11:55 PM, Suresh Marru <[email protected]> wrote: > Hi Vasanth, > > I tried to run it from CLion as I assumed from your code statement rupture > thats what you used to develop. Can you please change the boiler plate > README to instructions on how to run this SDK for Airavata? > > Thanks for your contribution, > Suresh > > > On Apr 26, 2018, at 5:05 PM, Vasanth Methkupalli <[email protected]> wrote: > > Hello Dev, > > This is the detailed report for the development of C++ Client. > > > > > > *C++ Client SDK with Airavata 0.17Problem Statement:The current C++ > libraries in the Airavata client SDKs are outdated. As mentioned in the > Jira Issue, an attempt has been made to resurrect the client libraries with > google OAuth 2.0 as an example. Following were the steps charted out to > facilitate the above development1. Request user-based tokens to > Airavata File Manager, essentially communicating with the KeyCloak server > and hitting the right API end point to get the tokens via an Authorization > Workflow.2. Use generated Authorization temporary code from different > kinds of flows like implicit flow, Direct Grants or Client Grants to a > token.3. Using token to generate a Credential Store and having a > skeletal implementation to use the credential store to Authenticate with > Airavata API.Approach:The entire process above has been broken down into > multiple tasks and researched on different kinds of ways it can be done. > This document, serves the purpose of mentioning all the different kinds of > approaches identified and why a particular procedure trumped over the > other. However, these observations may not be definite and more better > approaches can be suggested. But a good starting point and approach has > been the motive for development. Architecture for the problem statement:The > above problem involves developing an SDK to resurrect the client libraries. > The focus of this problem is however limited to OAuth 2.0, like the > reference with google clients. Following were the steps decided in the > workflow while deciding the architecture for the problem:1. Request > token using Curl, one of the primary reasons for using Curl has been the > C++ support in terms of libraries and typical HTTP requests made in the > Google C++ client libraries does not have the support of doing POST and GET > requests with a payload. Decided to use Curl to make requests with a > payload to accommodate, client_id, username, password among others. > Initially this has been tested on a sample KeyCloak server on localhost and > token successfully retrieved. So, basing along those lines this has been > converted into a cpp function and can be used later as a starting point for > an Authorization flow. 2. The above steps generates a json file which > can be used as a basis for building the authorization flow around it. We > create a flow from secret json file and check the status of it, if it is > successful we proceed to the next part of our development, i.e, developing > a credential store which can later be used for authentication purpose. One > of the flows which has been left out has been the implicit flow where we > generate a temporary code on which we build a permanent token. Also, an > interesting approach has been discovered, authentication with Client ID and > Client Secret or using JWT, it would have been interesting if C++ client > libraries in google reference had support for JWT, but since there was no > support for that approach. Choose to stick with using Client ID and Client > Secret for the authentication process. 3. The next step in the flow is > building a credential store, the entire process of setting up the HTTP > Transport layer, getting the Json file and setting up the authorization > flow has been done in startup, since any application needs to setup these > things first before we go about developing any application. 4. Once, we > have the credential store setup, it can be used against any application to > have authentication set and go about using the rest of the application. A > skeletal implementation with the function has been created. Future work can > start at that point by accessing the Airavata API and using the credential > stores to access the Application. Workflow Github: > https://github.com/MethkupalliVasanth/google-api-cpp-client > <https://github.com/MethkupalliVasanth/google-api-cpp-client>References:1) > https://github.com/wpic/sample-keycloak-getting-token > <https://github.com/wpic/sample-keycloak-getting-token>2) > > https://www.keycloak.org/docs/3.3/server_admin/topics/sso-protocols/oidc.html > <https://www.keycloak.org/docs/3.3/server_admin/topics/sso-protocols/oidc.html>3) > > https://google.github.io/google-api-cpp-client/latest/guide/data_reader.html > <https://google.github.io/google-api-cpp-client/latest/guide/data_reader.html>4) > https://google.github.io/google-api-cpp-client/latest/guide/json_data.html > <https://google.github.io/google-api-cpp-client/latest/guide/json_data.html>5) > > https://www.keycloak.org/docs/3.1/securing_apps/topics/oidc/java/client-authentication.html > <https://www.keycloak.org/docs/3.1/securing_apps/topics/oidc/java/client-authentication.html> > * > > >
