airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Should we use PasswordCallBack when creating server side classes
Date Sun, 25 Nov 2012 03:04:16 GMT
On Sat, Nov 24, 2012 at 9:46 PM, Amila Jayasekara
<thejaka.amila@gmail.com>wrote:

> 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.
>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message