Should we use PasswordCallBack when creating server side classes

[Chathuri Wimalasena <ka...@gmail.com>]

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.

Any idea how we can overcome that limitation ?

Thanks and Regards,
Chathuri

Re: Should we use PasswordCallBack when creating server side classes

[Saminda Wijeratne <sa...@gmail.com>]

Hi all,

I refactored the AiravataClientUtils to AiravataAPIFactory & overloaded the
getAPI function to have a non PasswordCallback.

Saminda

On Sat, Nov 24, 2012 at 10:06 PM, Suresh Marru <sm...@apache.org> wrote:

> Hi Amila,
>
> Sent from my iPhone
>
> On Nov 24, 2012, at 9:46 PM, Amila Jayasekara <th...@gmail.com>
> wrote:
>
> > Hi Saminda,
> >
> > Some comments inline.
> >
> > On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <sa...@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 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.
>
> Suresh
> >
> > 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 <sm...@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
> >>>> <ka...@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
> >>>
> >>>
>

Re: Should we use PasswordCallBack when creating server side classes

[Suresh Marru <sm...@apache.org>]

Hi Amila,

Sent from my iPhone

On Nov 24, 2012, at 9:46 PM, Amila Jayasekara <th...@gmail.com> wrote:

> Hi Saminda,
> 
> Some comments inline.
> 
> On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <sa...@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 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.

Suresh
> 
> 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 <sm...@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 <th...@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
>>>> <ka...@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
>>> 
>>> 

Re: Should we use PasswordCallBack when creating server side classes

[Saminda Wijeratne <sa...@gmail.com>]

On Sat, Nov 24, 2012 at 9:46 PM, Amila Jayasekara
<th...@gmail.com>wrote:

> Hi Saminda,
>
> Some comments inline.
>
> On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <sa...@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.
>
Completely agree... I've misunderstood you've said earlier... My bad.

>
> > 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.
>
Yep... We needed to make AiravataRegistryFactory generalized to support any
future user defined implementations. And right now through this Factory
class we are supporting 2 styles.. Pass credentials (url+credentials) or
just pass idenity (gateway+username) to create a Registry API Object.

>
> >
> > 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).
>
Yeah definitely... I'll add the overloaded version... And I think its
better to have the class as AiravataAPIFactory rather than
AiravataClientUtils I guess... Let me refactor introduce AiravataAPIFactory
& deprecate AiravataClientUtils.

Thanks for the feedback on the API,
Saminda


> 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 <sm...@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 <th...@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
> >> > <ka...@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
> >>
> >>
>

Re: Should we use PasswordCallBack when creating server side classes

[Amila Jayasekara <th...@gmail.com>]

Hi Saminda,

Some comments inline.

On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <sa...@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 <sm...@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 <th...@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
>> > <ka...@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
>>
>>

Re: Should we use PasswordCallBack when creating server side classes

[Saminda Wijeratne <sa...@gmail.com>]

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.
There are 2 RegitryAPI implementations at the moment.

   1. The Rest implementation - for clients
   2. The JPA implementation - for server-side

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?

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 <sm...@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 <th...@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
> > <ka...@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
>
>

Re: Should we use PasswordCallBack when creating server side classes

[Suresh Marru <sm...@apache.org>]

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 <th...@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
> <ka...@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

Re: Should we use PasswordCallBack when creating server side classes

[Amila Jayasekara <th...@gmail.com>]

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
<ka...@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