[kepler-dev] adding user login interface to Vergil

Tue Sep 13 12:08:35 PDT 2005

Just as a quick note, a Web browser is one example of a system in which
you don't log in at startup, but instead login occurs "at the source of
contact," i.e., when a particular application/web page is started. Note
also that there is some notion of multiple login accounts (stored
locally), certificate management, etc.

A similar "modality" could also be employed in Kepler (although I'm not
advocating either approach, just throwing it out there).

-shawn

Laura L. Downey wrote:
> 1.  Am I understanding you correctly that you are suggesting that as each
> workflow is run, if it uses a grid resource, that is when the kepler system
> would prompt a user to log in?  I assume a user would remain logged in until
> they specifically logged out.
> 
> The advantages to having a user log in upon start of the application are 1)
> it is fairly standard way of interaction in a network application 2) that
> he/she knows immediately what they have access to and 3) that they are
> logged in and won't have to interrupt their design and execution process
> later to log in.  4) Additionally, they will also figure out real quick if
> they need to apply for an account on a domain so they have access to desired
> resources etc.
> 
> Is there something I'm missing here?  Is there some advantage to not being
> "logged in" in terms of performance or something?  You seem to be placing a
> significant emphasis on people not having to log in or them working a lot of
> the time locally so it being some bother to the user to log in etc.  Do we
> anticipate that users will want to do lots of stuff locally?  I had assumed
> just the opposite that the most likely scenario is that users will want
> access to whatever they have permission for in order to fully exploit
> resources.
> 
> 2 & 3.  Without addressing some of the underlying technical issues since my
> focus is the user ;-) .... from a user perspective I think it will be
> important that users know/understand what they have access to, what they are
> allowed to do and run etc.
> 
> Laura L. Downey
> Senior Usability Engineer
> LTER Network Office
> Department of Biology, MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM  87131-0001
> 505.277.3157 phone
> 505.277-2541 fax
> ldowney at lternet.edu
>  
> 
> -----Original Message-----
> From: Zhijie Guan [mailto:guan at sdsc.edu] 
> Sent: Tuesday, September 13, 2005 11:40 AM
> To: 'Laura L. Downey'; 'Jing Tao'
> Cc: kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] adding user login interface to Vergil
> 
> Here are my concerns about user login and resources.
> 
> 1. I prefer Kepler system pops up a window for user login at the execution
> time. During design period, users don't need to input username/password once
> they add a Grid actor into the workflow. So I guess the director in each
> workflow should somehow check all the actors before initializing the
> execution, and then prompt for username/password/domain if any Grid actors
> are used. The director should also store the proxy created by GAMA server
> and finally destroy it when the workflow is finished/ceased. Thus, users who
> don't use Grid actors won't be bothered to log in. Yes. I agree a menu entry
> of user login now seems confusing. Kepler system should handle the whole
> issue instead of depend on users self consciousness.
> 
> 2. Resources, as well as access, need more discussion and specification.
> Resources could be data, programs (tools), a physical machine, a cluster,
> conceptual computing power, or even human interaction (like checking the
> result with EXPERIENCED EYES). Access could be retrieving the data,
> executing a program, consuming a web/grid service, or any combination of
> them. Note some resources only support one kind of access, like a FTP server
> only provides data access, users cannot run any program on it. If the
> "resources" means the "domains", we still need to know a user having access
> to a domain does not mean (s)he can run any kind of programs on any
> computers in that domain. I don't think I have a clear mind on this resource
> accessibility issue. I still need users (GEON/SEEK groups?) give me more
> feedback.
> 
> 3. The access permission is another issue related to resources and access.
> We have access to a resource does not mean we can fully control the
> resource, just like access to a directory in Unix does not mean the whole
> "rwx" permission. In a Grid environment, it may get to be more complicated
> with the Grid user account. A GIS+GSI architecture may satisfy our needs if
> we really want to build up a complete list for access permission of each
> access to each resource. But in that case, a Grid job scheduler should
> handle all the resource access control and job dispatch, as well as cover
> the details to the end user. To my understanding, the ultimate goal of
> workflow platform includes choosing the resources for the users, instead of
> letting users make the decision. I believe there is still a lot of
> research/development to do in this way. I would like to start our Kepler
> authentication framework with an easy, contact functional component while
> keeping all of those considerations in mind. 
> 
> 
> Zhijie
> 
> 
> 
> -----Original Message-----
> From: Laura L. Downey [mailto:ldowney at lternet.edu] 
> Sent: Tuesday, September 13, 2005 8:19 AM
> To: 'Jing Tao'; 'Zhijie Guan'
> Cc: kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] adding user login interface to Vergil
> 
> A few additional comments....
> 
> No worries Matt on not commenting on the log in and authentication screens.
> I put them together quickly.  The mockups were to give the general design
> idea that goes along with the proposed overall re-design.  
> 
> The reason I suggested to Zhije to have a look was not to imply that it was
> a final design but just to give an idea of the overall design so that he
> didn't mock something up that didn't fit.  Just trying to get us moving in
> the general direction of the proposed re-design as we make changes so we
> have less to change later on when we get the full re-design implemented.
> 
> The wording on the dialogs can easily be changed and I even made reference
> to that.  Deana made the same comment about the word "demo" being used and I
> only used it because it is used in the problem description on the wiki page
> (demo account).  No problem with choosing something different.  Same goes
> for the placeholder "email XXX for an account."  I didn't have anything
> specific so just stuck that in there.
> 
> As to the user being prompted to log in, Ilkay and I discussed that and it
> was my understanding that was the way things were to be designed so I went
> with that.  I don't think users would be confused at having to log in to the
> application at the beginning, I believe that is fairly standard on
> networking applications that use distributed resources.  And people using
> the local resources versus grid resources is analogous to working offline
> and online which is also somewhat standard in networked applications.
> 
> I think it would be more confusing for the user not to be prompted to log in
> and think they have access, only to realize later they don't and have to go
> looking for a place to "log-in" to get access to other resources.  Logging
> in at the beginning of a session or use of an application seems the most
> logical and standard approach to me.  And if users consciously log out, then
> want to log back in, they are aware because they made the choice.  But to
> just open the app and expect them to know they are not logged in doesn't
> seem the best design in my experience.
> 
> In terms of the issue of resources, that is a general term and could mean
> "domain" if we need it to.  Perhaps I have misunderstood the requirements
> here but I thought it was necessary that users know what they have access to
> and what they don't.  I know if I was a user this information would be
> important.  Especially if they are doing searching and see a resource
> returned but can't get it because they don't have permission etc.  Or if
> they want to run a workflow remotely but don't have access to the domain or
> resource that workflow is on.
> 
> Again, the mockups were designed as an interim solution until we get a more
> sophisticated role-based access model working which may make the problem of
> knowing which resources a user has access too a moot point.
> 
> Laura L. Downey
> Senior Usability Engineer
> LTER Network Office
> Department of Biology, MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM  87131-0001
> 505.277.3157 phone
> 505.277-2541 fax
> ldowney at lternet.edu
>  
> -----Original Message-----
> From: Jing Tao [mailto:tao at nceas.ucsb.edu] 
> Sent: Monday, September 12, 2005 4:55 PM
> To: Zhijie Guan
> Cc: Laura L. Downey; kepler-dev at ecoinformatics.org
> Subject: Re: [kepler-dev] adding user login interface to Vergil
> 
> Hi, Zhijie:
> 
> See my comment below the text.
> 
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
> 
> On Mon, 12 Sep 2005, Zhijie Guan wrote:
> 
> 
>>Date: Mon, 12 Sep 2005 13:32:34 -0700 (PDT)
>>From: Zhijie Guan <guan at sdsc.edu>
>>To: Laura L. Downey <ldowney at lternet.edu>
>>Cc: kepler-dev at ecoinformatics.org
>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>
>>
>>That post is realy great. Sorry I forgot to get track on this. I did
>>check the prototypes when you posted, and thought they were just a general
>>idea instead of real implementation. It's my fault.
>>
>>Just a few comments. I cannot post it on wiki pages since I do not have an
>>account yet.
>>
>>1. The Kepler user may not "have to" log in before using Kepler. Though
>>most of our users will be registered with the GAMA server, we still have
>>some users who do not belong to any current-known group. An anonymous user
>>account may be the alternative solution. But I doubt the users would like
>>to log in when they just want to use their local resources. That's why I
>>suggest the authentication dialog is integrated as a menu entry. So users
>>can log in when necessary.
>>
> 
> 
> I agree with you. If user didn't log in, it runs kepler as public and 
> he/she has a limit to access some resources.
> 
> 
> 
>>2. For the "domain" part, I am not sure if we still need to know the
>>user's domain(s). I remember Jing said the GAMA server (actually the
>>MyProxy) could contact various LDAP servers to get the user
>>authentication. In that case, no domain info is needed. We can either use
>>the user-inputed domain info to locate the LDAP server, or let the GAMA
>>server do the flooding search.
>>
> 
> 
> Does the domain mean Organization? If it does, I think we need the domain 
> part, otherwise user should input the string  looks like 
> "uid=john,o=NCEAS...". It is pain for user.
> 
> MyPoxy can contact to one main LDAP server, and main LDAP may referral to 
> another LDAP server according to organization info for the user. So our 
> system need domain info and it is convenient for user just select an 
> domain for option list.
> 
> 
> 
>>Jing: Since we have the user interface already, should we start the design
>>of the AuthenticationManager as you mentioned?
>>
> 
> Yep, we can start it now. We can discuss it with matt, lkay and efrat.
> 
> 
> 
>>Thanks!
>>
>>Zhijie
>>
>>
>>On Mon, 12 Sep 2005, Laura L. Downey wrote:
>>
>>
>>>I'm confused.  I made a post to seek-dev about the log-in screen and
> 
> pointed
> 
>>>people to the wiki some time ago.  Here's the url to the log-in and
>>>authentication mockups:
>>>
>>>http://kepler-project.org/Wiki.jsp?page=KeplerAuthenticationFramework
>>>
>>>I asked for feedback and got a few minor comments.
>>>
>>>The proposal was for the user to have to log in before getting to the
> 
> other
> 
>>>Kepler screens so not really a need for a log-in menu item -- this was a
>>>first cut solution until we add in more sophisticated role based access
> 
> etc.
> 
>>>Laura L. Downey
>>>Senior Usability Engineer
>>>LTER Network Office
>>>Department of Biology, MSC03 2020
>>>1 University of New Mexico
>>>Albuquerque, NM  87131-0001
>>>505.277.3157 phone
>>>505.277-2541 fax
>>>ldowney at lternet.edu
>>>
>>>
>>>-----Original Message-----
>>>From: Matt Jones [mailto:jones at nceas.ucsb.edu]
>>>Sent: Monday, September 12, 2005 1:00 PM
>>>To: Zhijie Guan
>>>Cc: Laura L. Downey; kepler-dev at ecoinformatics.org
>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>
>>>Zhijie,
>>>
>>>Those dialogs ahve already been prototyped but not fully reviewed before
>>>implementaiton starts.  Maybe Laura could post them on the usability
>>>page or somewhere else on the wiki so that we can all comment before you
>>>start implementing?  Thanks,
>>>
>>>Matt
>>>
>>>Zhijie Guan wrote:
>>>
>>>>Thanks for pointing me to the right issue. I've read the wiki webpage on
>>>>http://kepler-project.org/Wiki.jsp?page=KeplerUsability, which includes
>>>>the proposal of Kepler redesign and Kepler Symbology. It is quite
>>>>interesting to see a new look of Kepler.
>>>>
>>>>For the changes I would make, they are only a menu entry and a user
> 
> login
> 
>>>>dialog. They should be easily adapted to any schema/rationale with minor
>>>>changes on the source code. And finally I will submit my changes to
> 
> Ilkay
> 
>>>>for CVS check in.
>>>>
>>>>Thanks!
>>>>
>>>>Zhijie
>>>>
>>>>On Mon, 12 Sep 2005, Laura L. Downey wrote:
>>>>
>>>>
>>>>
>>>>>Before making lots of changes, I would suggest that you look at the
>>>
>>>proposed
>>>
>>>>>re-design for the user interface.  Also, I've already designed the user
>>>
>>>log
>>>
>>>>>in screens and generally how they will be integrated into that design.
>>>>>
>>>>>I'd post the pointer to the wiki page but I can't seem to get the
> 
> Kepler
> 
>>>>>project pages to display at the moment.
>>>>>
>>>>>Laura L. Downey
>>>>>Senior Usability Engineer
>>>>>LTER Network Office
>>>>>Department of Biology, MSC03 2020
>>>>>1 University of New Mexico
>>>>>Albuquerque, NM  87131-0001
>>>>>505.277.3157 phone
>>>>>505.277-2541 fax
>>>>>ldowney at lternet.edu
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: kepler-dev-bounces at ecoinformatics.org
>>>>>[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Zhijie Guan
>>>>>Sent: Wednesday, September 07, 2005 4:49 PM
>>>>>To: kepler-dev at ecoinformatics.org
>>>>>Subject: [kepler-dev] adding user login interface to Vergil
>>>>>
>>>>>Dear All,
>>>>>
>>>>>I get a question for editing the "graph editor" user interface. I am
> 
> going
> 
>>>>>to implement the single login user interface for Kepler authentication
>>>>>framework. Thus, I need to add a menu entry into the "Graph Editor"
> 
> user
> 
>>>>>interface. When user click this menu entry, the system should pop up a
>>>>>dialog to let user input username and password. But I don't know where
> 
> I
> 
>>>>>should start in order to edit the user interface (Vergil?). I am pretty
>>>>>new to the Kepler code jungle. Could anyone point me any source
>>>>>code/development documents that I should read?
>>>>>
>>>>>Thank you!
>>>>>
>>>>>Regards,
>>>>>
>>>>>Zhijie Guan
>>>>>
>>>>>_______________________________________________
>>>>>Kepler-dev mailing list
>>>>>Kepler-dev at ecoinformatics.org
>>>>>
> 
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 
>>>>
>>>>_______________________________________________
>>>>Kepler-dev mailing list
>>>>Kepler-dev at ecoinformatics.org
>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>
>>
>>
>>
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
> 
> 
> 
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev