[kepler-dev] adding user login interface to Vergil

Matt Jones jones at nceas.ucsb.edu
Fri Sep 16 08:48:06 PDT 2005


Zhijie,

In contrast to your last paragraph, I think there will be multiple GAMA 
servers that Kepler accesses.  At a minimum, there will be one GEON GAMA 
server and one SEEK GAMA server.  There may be more.  The "domain" is a 
name that maps to the GAMA server to which a user wants to authenticate. 
The SEEK GAMA server will provide certificate services on top of an 
already existing LDAP-based authentication system that is used across 
several institutions.  This system is not centralized, and so in 
addition to to username, we need an organization string to distinguish 
which backend LDAP server to use for authentication.  This 
"organization" string is analogous to the "domain" string in function.  
So, here's what I was thinking we would use our current "organization" 
strings as the "domain" fields for our server, so we meight have a list 
of domains like this configured in Kepler:

Domain            GAMA Server
-------------     ----------------------
GEON         ==>  GEON GAMA Endpoint
LTER         ==>  SEEK GAMA Endpoint
OBFS         ==>  SEEK GAMA Endpoint
UCNRS        ==>  SEEK GAMA Endpoint
PISCO        ==>  SEEK GAMA Endpoint
etc.

These would be given as a drop-down menu in the login interface.

As far as the account creation API goes, I think we should hold off on 
is inclusion.  There are a wide variety of mechanisms for maintaining 
accounts that are in use (that collect different types of information), 
and we need to accomodate them all if we're going to realistically have 
account creation tools be used.

Matt

Zhijie Guan wrote:

>Hi, Jing,
>
>Thanks for your comments. I have updated the AuthenticationFrame webpage
>to provide a new solution for single AuthenticationManager. Please check
>the website. And see my response below.
>
>Zhijie
>
>
>>1) Do we need createUsers and deleteUsers method in AuthenticationManager?
>>I think those tasks is for admin of users. It is not part of Kepler task.
>>Maybe we need some web interface to do it, rather than Kepler.
>>
>
>Yes. I prefer a web interface to manage the user accounts too. But this
>API is also a web service running on GAMA server. It's not part of Kepler
>either. I am not sure if we really need those methods here. I just put
>those methods here as the "placeholder", in case in the future the admin
>web interface wants to use these methods, i.e., web interface could be
>able to manage user accounts through this API too.
>
>
>>2) It seemes one of AuthenticationManager object will handle one
>>user(beause there are username and passwd fields in this class). And using
>>singleton ProxyRepository class keeps track the user's proxy. I think
>>probably we can make AuthenticationManager as a singleton class and every
>>method will have username, password, domain(I think domain is to tell
>>differnt gama server) as signature. So class will be called like:
>>AuthenticationManager.getInstance().getProxy(username, password, domain);
>>
>>So we only have one manager :)
>>
>
>That's a good idea. Actually in the original design, the system needs to
>synchronize the access of ProxyRepository generated from multiple
>AuthenticationManager. That is not a easy job. Some access locks may need
>to be used, and mutual-locking mechanism need to be maintained.
>
>One AuthenticationManager can ease the implementation of ProxyRepository.
>But I think it also has its own problem. We assume the client side
>(workflow director) will access the Authentication Framework following the
>routine, like call createProxy at the beginning, and destroyProxy
>eventually. But if one erroneous client side could call once createProxy
>and then call the destroyProxy twice, the AuthenticationManager may get
>into trouble. Since the AuthenticationManager cannot distinguish the
>users, and it does not track the proxies issued, it may destroy the proxy
>which may still been using by other clients in the case described above. I
>think more bookkeeping work need to be implemented in
>AuthenticationManager in order to address this deficiency.
>
>It's not easy to get a sound, complete and self-defensive solution. B->
>
>>3) In keper we may have different authentication service(seek GAMA, GEON
>>GAMA). Is the domain in the API for telling them? We need more
>>clarification for username and domain's defination.
>>
>
>To my understanding, we only have one authentication service, i.e., one
>GAMA server, for the whole authentication framework. This GAMA server will
>coordinate all of the LDAP servers for all the user groups (domains?). I
>am not clear about the use of domain. But I guess it could be used to
>decide which LDAP server the GAMA should contact to.
>
>
>>Thanks.
>>
>>Jing
>>
>>
>>
>>
>>Jing Tao
>>National Center for Ecological
>>Analysis and Synthesis (NCEAS)
>>735 State St. Suite 204
>>Santa Barbara, CA 93101
>>
>>On Wed, 14 Sep 2005, Zhijie Guan wrote:
>>
>>
>>>Date: Wed, 14 Sep 2005 15:01:26 -0700
>>>From: Zhijie Guan <guan at sdsc.edu>
>>>To: 'Matt Jones' <jones at nceas.ucsb.edu>
>>>Cc: kepler-dev at ecoinformatics.org
>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>
>>>Dear All,
>>>
>>>I have put the API programming specification for the AuthenticationManager
>>>(Authentication Framework) on our project website. Please visit
>>>http://kepler-project.org/Wiki.jsp?page=KeplerAuthenticationFramework and
>>>give me your valuable feedback.
>>>
>>>Thanks!
>>>
>>>Zhijie
>>>
>>>-----Original Message-----
>>>From: Matt Jones [mailto:jones at nceas.ucsb.edu]
>>>Sent: Tuesday, September 13, 2005 3:24 PM
>>>To: guan at sdsc.edu
>>>Cc: 'Laura L. Downey'; kepler-dev at ecoinformatics.org
>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>
>>>Hi Zhijie,
>>>
>>>Thanks for the nice summary.  As for your question: what use is
>>>authentication without authorization?  Well, I never argued we wouldn't
>>>have authorization.  Just that we don't have much chance of a shared
>>>infrastructure for it over the short term.  Which means that each actor
>>>has to decide how it interacts with the authorization service on the
>>>backend on an ad-hoc basis, which is how we're doing it now.  Its also
>>>how we are passing credentials to the backend services now (ad-hoc), and
>>>a shared authentication framework still doesn't change that.  For
>>>example, the SRB actors currently handle authorization by passing
>>>credential info to the backend srb server using srb-specific APIs.  The
>>>SRB server then determines whether access to a given object is
>>>authorized or not.  Kepler knows little about it.  Same is true for
>>>metacat, etc.  Globus uses grid-map files for authorization, which isn't
>>>amenable to export to other systems.  We can continue using this
>>>approach, but slowly build towards a shared system by at least initially
>>>agreeing on a mechanism for authentication.  Its a step forward, albeit
>>>a small step, in that actors would now have a uniform API for getting
>>>credentials from a user (as opposed to the ad-hoc use of password
>>>paramters and config files currently in use in kepler).
>>>
>>>Matt
>>>
>>>Zhijie Guan wrote:
>>>
>>>>Ok. Let me summarize our discussion here.
>>>>
>>>>1. We agree we need a user login dialog, no matter it pops up at Kepler
>>>>startup or per Grid actor's request.
>>>>
>>>>2. We are building an "authentication" framework. So if a user has logged
>>>>into the system, then we know (s)he is recognized/identified by the
>>>>
>>>system.
>>>
>>>>That does not mean the system would grant any "access" permission to the
>>>>user.
>>>>
>>>>3. It's users' responsibility to make sure they have the right permission
>>>>
>>>to
>>>
>>>>run their workflows on the Grid resources they claimed. Kepler
>>>>authentication framework only makes sure that the user is whom (s)he
>>>>
>>>claimed
>>>
>>>>to be.
>>>>
>>>>4. We should list the domains that a user gets authenticated to after the
>>>>user logged in.
>>>>
>>>>5. We still get a long way to go toward the shared infrastructure for
>>>>authorization.
>>>>
>>>>Here comes my question:
>>>>If authentication is separated from authorization, and we currently do not
>>>>have energy to deal with authorization, then why do we really need
>>>>authentication framework? I know the authentication (login) can let the
>>>>system know who you are. But I don't want to make changes just for getting
>>>>
>>>a
>>>
>>>>popup saying "Hello Zhijie, Welcome to Kepler!" Obviously our Kepler does
>>>>not handle accounting stuff, so it won't sending you a bill every month to
>>>>let you know how long you've used Kepler. If the login cannot authorize
>>>>
>>>the
>>>
>>>>user to use some resources, why bother to login?
>>>>
>>>>Well. I should say our authentication framework does some job on
>>>>authorization. The proxy returned by GAMA server gives the user a kind of
>>>>permission to run programs on some servers. The permission is granted by
>>>>
>>>the
>>>
>>>>user's certificate and the server's configuration. To let a GEON user run
>>>>
>>>a
>>>
>>>>program on a SEEK server, we only need to set an entry for the user in the
>>>>grid-mapfile on the SEEK server. The GEON user may not even need to be
>>>>"authenticated" by the SEEK LDAP server. So running a workflow depends on
>>>>authorization instead of authentication. Then why we need authentication?
>>>>
>>>>I think I get myself confused enough. B->
>>>>
>>>>Zhijie
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: kepler-dev-bounces at ecoinformatics.org
>>>>[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Laura L.
>>>>
>>>Downey
>>>
>>>>Sent: Tuesday, September 13, 2005 1:08 PM
>>>>To: 'Matt Jones'
>>>>Cc: kepler-dev at ecoinformatics.org
>>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>>
>>>>Okay well I guess I'm confused over this whole issue then.  Because I
>>>>thought I understood from discussions with Ilkay that we wanted to let the
>>>>users know on some high level what they have access to.  And yes I know
>>>>
>>>just
>>>
>>>>because you have permission to access a specific server doesn't mean you
>>>>have access to every single file on that server.  I log on to lternet.edu
>>>>and I don't have access to all files but I know I'm logged in at least and
>>>>have access to some of the resources there.  If I not logged in then I
>>>>
>>>know
>>>
>>>>I can't get to anything there.
>>>>
>>>>And reading some of the other comments today it appears that we are saying
>>>>people will have to "log in" and be authenticated to various domains.
>>>>
>>>What
>>>
>>>>am I missing here?  I thought we were going to a single sign on so that
>>>>users didn't have to sign on to tons of different systems....
>>>>
>>>>My head hurts... ;-)
>>>>
>>>>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: Tuesday, September 13, 2005 1:56 PM
>>>>To: Laura L. Downey
>>>>Cc: kepler-dev at ecoinformatics.org
>>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>>
>>>>Hi Laura,
>>>>
>>>>Laura L. Downey wrote:
>>>>
>>>>
>>>>>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.
>>>>>
>>>>
>>>>Well, having authenticated to a domain (aka ~server) implies nothing
>>>>about whether a user may or may not have access to the objects on that
>>>>or related  servers.  So saying a user has been "authenticated" to a
>>>>server (which we can list) tells us nothing about what they have access
>>>>to on that server.  So we can not generate even a high-level list of
>>>>resources they can access.
>>>>
>>>>Matt
>>>>
>>>>
>>>>
>>>>>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
>>>>>
>>>>>
>>>>
>>>--
>>>-------------------------------------------------------------------
>>>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
>>>
>>>
>>>
>



More information about the Kepler-dev mailing list