[kepler-dev] adding user login interface to Vergil

[Laura L. Downey]

Oh agreed Matt -- and I never meant that we should be listing individual
objects at the various domains -- like I said I was using resources in a
broad general context.  I would expect the list to be something like the
sources offered to be searched.  Maybe this is just a terminology issue?

Just trying to think of a way that a user knows what they have access to at
a high level -- like saying you have access to this server and that server
which means all the various data items on those servers. 

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 Matt Jones
Sent: Tuesday, September 13, 2005 1:23 PM
To: Matt Jones
Cc: kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] adding user login interface to Vergil

And just to clarify why I think the resource list is a long list...

Workflows do not reference systems like metacat or SRB, but rather they
reference resources (objects) stored on those systems or services
accessible through those systems (e.g., web services).  Authorization is
done at the resource level, not the system level.  So one can't say "Joe
has read access to SRB" because that is meaningless -- its at the wrong
granularity.  Rather, the statement is "Joe has read access to
object.231", where object.231 happens to be stored on SRB.  Listing all
of the objects and services to which a user might have access is a very
long list.  In the GUI, listing the systems to which is user has access
is non-sensical because authorization is done at a different grain.
However, listing the domains to which they are authenticated would make
sense, even though its not everything one needs to know to determine if
a workflow can be run.

Matt

Matt Jones wrote:
> 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-de
v
>>>>
>>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>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
-------------------------------------------------------------------
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev