[kepler-dev] adding user login interface to Vergil

Wed Sep 14 15:01:26 PDT 2005

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