[kepler-dev] adding user login interface to Vergil

Thu Sep 15 22:42:13 PDT 2005

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
> >
> >
>