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