[kepler-dev] adding user login interface to Vergil

Matt Jones jones at nceas.ucsb.edu
Tue Sep 13 12:14:17 PDT 2005


The issue that will come up is this: which system does one log into at
startup?  Lets say a GEON user fires up kepler and opens a Geo workflow
-- should they log into the SEEK domain?  Probably not. How about a SRB
system?  Probably not.  How about the DiGIR network?  Probably not.
Why? Because authentication against the SEEK, SRB, and DiGIR domains is
irrelevant to the particular GEON workflow -- rather, they should
authenticate against the GEON domain because the workflow accesses
resources that they can access using their GEON domain identity.  If we
had centralized authentication, which we don't, and almost certainly
won't, then this wouldn't be an issue.  But so far our discussions have
led us to supporting multiple authentication servers, so we need to deal.

Second, we need to differentiate *authentication* and *authorization*
here.  When we talk about logging in, that is only authentication, and
has no bearing on authorization.  Plus, any given user can be
authenticated against multiple domains simultaneously (e.g., SEEK,
GEON).  In contrast, most of Zhijie's comments about controlling
resources have to do with authorization -- that is, determining whether
a given principal has rights to do something with a resource (ie, read,
write, execute, etc).  We have not yet discussed any shared
infrastructure for authorization, because it is a MUCH harder problem.
We've hinted that it would be nice if individual actors could tell the
system something about their authorization needs (ie, user must be
authenticated against the GEON domain, or some such), so that the system
could prompt the user to log into the right domain, only when needed,
but we really haven't thought this through.

In the Metacat, we (mostly) use access control (authorization) rules *in
the metadata documents* to govern resource access.  I don't know how it
works in GEON.  SRB has its own access system API for setting
authorization rules.  Grid systems use various technologies too,
although the development of SAML and CAS are probably steps in the right
direction.  At this point I think we are not yet ready to intelligently
deal with authorization comprehensively because the back-end systems are
very diverse, even though it would improve usability a lot.

So lets tackle authentication, then deal with authorization in a second
step.  Unfortunately, this means we can NOT list the resources to which
a user has access (and, that would be such a long list anyways it would
be useless).

My $0.02.
Matt


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

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------


More information about the Kepler-dev mailing list