airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DImuthu Upeksha <dimuthu.upeks...@gmail.com>
Subject Re: C++ Client SDK with Airavata 0.17
Date Mon, 30 Apr 2018 15:55:31 GMT
Hi Vasanth,

There are couple of suggestions.

I'm still figuring out where to start testing your SDK client. Seems like
you have forked google cpp client and updated your sample in it which is
not the way you should follow. You should update a fork repository only if
you a doing an improvement to that original repository. In your case, your
changes are only beneficial to you (or us in future) but not google cpp
client. So I think you should create your own repository and add google cpp
client as a dependancy to your project.

Are you using a pure curl command [2] to talk to keycloak API inside c++? I
think this is good only for testing purposes but when you are going to use
this in a real production environment, you might have to think about corner
cases like possible errors. For example let's say that the keycloak
endpoint is temporary unavailable. Then how do you handle 404 error codes?
I strongly recommend you to use a recommended http client library [3] to
handle external http calls from a c++ code. If you have done so, please
ignore this suggestion.

[1] https://github.com/google/google-api-cpp-client
[2] https://github.com/wpic/sample-keycloak-getting-token
[3]
https://stackoverflow.com/questions/822581/what-c-library-should-i-use-to-implement-a-http-client

Thanks
Dimuthu

On Fri, Apr 27, 2018 at 12:09 AM, Vasanth Methkupalli <vasmethk@iu.edu>
wrote:

> 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 <smarru@apache.org> 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 <vasmethk@iu.edu> 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>
>> *
>>
>>
>>
>

Mime
View raw message