airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re: Should we use PasswordCallBack when creating server side classes
Date Sun, 25 Nov 2012 02:46:23 GMT
Hi Saminda,

Some comments inline.

On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <samindaw@gmail.com> 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 components.

> 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).

Thanks
Amila

>
> Saminda
>
> 1.
> https://svn.apache.org/repos/asf/airavata/trunk/modules/registry/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistryFactory.java
> 2.
> https://svn.apache.org/repos/asf/airavata/trunk/modules/registry/registry-api/src/main/java/org/apache/airavata/registry/api/AiravataRegistryConnectionDataProvider.java
> 3.
> https://svn.apache.org/repos/asf/airavata/trunk/modules/airavata-client/src/main/java/org/apache/airavata/client/AiravataClientUtils.java
> On Thu, Nov 22, 2012 at 2:33 PM, Suresh Marru <smarru@apache.org> 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 <thejaka.amila@gmail.com>
>> 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
>> > <kamalasini@gmail.com> 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 a
>> >> 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
>>
>>

Mime
View raw message