On Sat, 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 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 <[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 > >> > >> >
