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 <[email protected]> wrote: > Hi Amila, > > Sent from my iPhone > > On Nov 24, 2012, at 9:46 PM, Amila Jayasekara <[email protected]> > wrote: > > > Hi Saminda, > > > > Some comments inline. > > > > On Sat, Nov 24, 2012 at 2:24 PM, Saminda Wijeratne <[email protected]> > 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 <[email protected]> > 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 <[email protected] > > > >>> 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 > >>>> <[email protected]> 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 > >>> > >>> >
