[kepler-dev] adding user login interface to Vergil
Jing Tao
tao at nceas.ucsb.edu
Wed Sep 14 16:39:51 PDT 2005
Hi, Zhijie:
The API looks very good. Here is some comments:
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.
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 :)
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.
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