airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: Should we use PasswordCallBack when creating server side classes
Date Sun, 25 Nov 2012 03:06:11 GMT
Hi Amila,

Sent from my iPhone

On Nov 24, 2012, at 9:46 PM, Amila Jayasekara <> wrote:

> Hi Saminda,
> Some comments inline.
> On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <> wrote:
>> Well, IMO when a client triggers an action which propagates to server-side,
>> the user identity needs to propagate to server-side even to the GFaC end.
> The user identity should propagate to GFac level. But this doesn't
> mean we need to pass credentials all the way through. The main purpose
> of password callback is to get the password from user. As user's
> identity we only need user name (it could be something else in future,
> like open id, SAML token etc ...). User name information should
> wrapped in a context relevant to request and should be made available
> to all server components. My initial argument is not to have password
> callback in server component

I agree, server only need user name and assume authentication and authorization is done prior.

>> There are 2 RegitryAPI implementations at the moment.
>>   1. The Rest implementation - for clients
>>   2. The JPA implementation - for server-side
> This is fine. Then we should only have password callback for REST
> implementation.
>> JPA implementation does not rely on password callback (although the Rest
>> impl does - we have 2 functions to handle these 2 scenarios in
>> AiravataRegistryFactory[1]). Assuming a security layer already handled the
>> authentication (Registering a AiravataRegistryConnectionDataProvider should
>> handle if any other data is needed).
>> However the AiravataClientUtils[3] does not have a function call without a
>> password callback to create an API object although you can pass "null"
>> without harm. For now we can update the AiravataClientUtils to have
>> functions having without password callback. WDYT?
> I am not quite sure about the role of AiravataClientUtils. I believe
> this is used in both above API's (?). Also that is mainly what
> Chathuri is confused over. (Chathuri correct me if I am wrong).
> If that is the case we can go a head with what Saminda suggested.
> Minor implementation detail - Would be nice to use overloading instead
> of passing null. (If possible).
I agree, the confusion is increasing. I will try and clarify with some architecture, but will
need every ones input until we all get to same page.

> Thanks
> Amila
>> Saminda
>> 1.
>> 2.
>> 3.
>> On Thu, Nov 22, 2012 at 2:33 PM, Suresh Marru <> wrote:
>>> Hi Amila,
>>> I think this needs clean up. We should have Airavata Server API (which in
>>> the future should be implemented by a Airavata Service API). GFac and other
>>> services should based on this server API. But clients should have a light
>>> weight client api which should PasswordCallback as you and Chathuri are
>>> discussing.
>>> Volunteers for fracturing the API into client and server functions?
>>> Saminda, naturally you have the most insights into this, will you time to
>>> get to this before the next release?
>>> Suresh
>>> On Nov 22, 2012, at 1:05 PM, Amila Jayasekara <>
>>> wrote:
>>>> Hi Chathuri,
>>>> Some answers in-line. In summary password callback should be used only
>>>> in the client side. This provides a way to get password in a way
>>>> client preferred.
>>>> E.g :- In XBaya like GUI clients need to get password from UI. So
>>>> PasswordCallback provides a mechanism to implement these scenarios.
>>>> We do not need password callback in server side. It seems the
>>>> complication is due to use of same AiravataAPI in server side. As per
>>>> what I understood Airavata API should be used in client side only. I
>>>> am not quite sure why we are using AiravataAPI at GFac level. Thus
>>>> server side components such as GFac should not use user passwords.
>>>> Maybe Lahiru or Saminda can give more details about why we use
>>>> AiravataAPI at other server side components.If AiravataAPI is
>>>> necessary for other server side components such as GFac, probably we
>>>> should create another abstraction of AiravataAPI without password
>>>> callback.
>>>> Thanks
>>>> Amila
>>>> On Thu, Nov 22, 2012 at 12:40 PM, Chathuri Wimalasena
>>>> <> wrote:
>>>>> Hi All,
>>>>> In the process of replacing registry calls of XBaya with
>>> AiravataClient, we
>>>>> had to change some classes in GFac and workflow interpreter services
>>> which
>>>>> are instantiated from Xbaya. What we did was, we replace
>>> AiravataRegistry2
>>>>> object with AiravataAPI object in those classes. For an example, have
>>>>> look in to GFacConfiguration class.
>>>>> To create the AiravataAPI class, we need to pass registryURL, gateway,
>>>>> username and passwordCallback object. This PasswordCallback is a client
>>>>> specific implementation of PasswordCallBack interface. Same
>>>>> PasswordCallback object is necessary when creating AiravataRegistry2
>>> object
>>>>> as well. IMO, we should not use PasswordCallback instance in the server
>>>>> side classes.
>>>> I agree with you. We should not use Password callback in server side.
>>>>> Any idea how we can overcome that limitation ?
>>>> I think to solve this first we need to figure out why we use
>>>> AiravataAPI in server side components. Above i wrote some thoughts.
>>>>> Thanks and Regards,
>>>>> Chathuri

View raw message