[seek-dev] [kepler-dev] GAMA server for SEEK

[Zhijie Guan]

Here are my two cents.

On Fri, 26 Aug 2005, Bill Baker wrote:

> A few notes below.
>
> -- Bill
>
> At 12:34 2005-08-26, Jing Tao wrote:
>> Hi, everyone:
>>
>> After talking with Bill and Sandeep and reading the documentation, here is
>> some thought about adopt GAMA and MyProxy which connects to LDAP as our
>> authentication server.
>>
>> To my understanding, MyProxy in NCSA is configured to use external
>> authentication mechanisam - LDAP to verify identity. So user input usrname
>> and password into MyProxy, and MyProxy connects PAM though PAMClient, then
>> connects LDAP. LDAP will authenticate the user base on the given username
>> and password. The authentication result (true or false) from LDAP will be
>> sent back to MyProxy. Here is an issue there: current user only input the
>> common name to MyProxy and MyProxy will construct distinguish name by some
>> mechanism(not sure if it's by hard code or property file). Because we will
>> support  different organization, the user name should be DN rather than CN
>> when it is sent to MyProxy. Probably we need to modify the source code
>> (Implemented by c).
>
> MyProxy doesn't actually modify the username before passing it to
> PAM.  Instead, in my testing I configured OpenLDAP to only search for the
> user within a single organization.  You might be able to change the
> OpenLDAP configuration to do a broader search as long as it is given a more
> specific username.  Any changes you need to make can probably be
> accomplished through PAM and OpenLDAP configuration -- the MyProxy code
> doesn't include anything specific to LDAP.
>
>> CACL and MyProxy are my interested components in GAMA. Through some GAMA
>> web service, CACL component is used to generate or delete user credential.
>> It is the user management tools in GAMA. Through another web service, user
>> credential can be copied to MyProxy. And through a web service in GAMA,
>> user can login and get back a proxy which was created in MyProxy component.
>>
>> Since MyProxy server is configurable in GAMA, it is reasonable way let
>> GAMA server point to a MyProxy server which connect LDAP server. So we can
>> use existed accounts in LDAP server for authentication.
>>
>> But here is still some things need be considered:
>>
>> 1. GAMA server stores credential in central place, do we need this
>> approach even our LDAP server is distruted? I think it is fine to store
>> credential centrally because it will remove the LDAP admin's burden to
>> manage them. And in this system, LDAP is an authentication tool and it
>> don't need to handle the credential.
>
> That sounds right to me.
>

I am confused here. How many LDAP servers there exist in our system? If we 
have two LDAP servers (one for each domain), can they communicate and 
search the user in each other? If there is no such communication 
mechanism, how does the MyProxy know which LDAP server it should send the 
user authentication request to? Can PAM mediate the search result between 
different LDAP servers?


>> 2. We need a mechanism to call GAMA web servcie to generate credential
>> when a new user registers in the community.
>
> Yes -- that will require some development.  A perl script or something?
>
>> 3. For existed user in our LDAP system, we need a mechanism to generate
>> credentials for them.
>
> Yes.  Presumably a mechanism similar to 2.
>

I think we'd better implement the user registration with a website instead 
of in a user interface of the kepler system. If a website can take care of 
the credential registration issue for new users and existing users, the 
Kepler single login interface can focus on the functions of log in/out. 
The website server could be bundled with the GAMA server. In the future 
when more and more users from different organizations/domains want to use 
this authentication architecture, they may want to set up their own GAMA 
server and website, instead of sharing the same GAMA server with 
SEEK/GEON. The benefit is the single login interface in Kepler could still 
survive and keep being a configurable component.

>> 4. When user resets password, we need an mechanism to generate credential
>> again(Maybe this mechanism is as same as the one for new user).
>
> Actually, the old credential can still be used if you store it unencrypted
> in GAMA/MyProxy.  In order to simplify credential management, I think you
> should do everything you can to let each user keep the same credential
> permanently (or until the credential expires).
>
> I think the problem you are referring to is that if the LDAP password
> matches the credential passphrase, then if you change the LDAP password,
> you can no longer use it to decrypt and access the credential.  That's
> true.  However, the credential does not need to be encrypted -- it just
> needs some sort of access control to protect it.  In this case, LDAP
> authentication can provide that access control, limiting access to people
> who know the LDAP password and to administrators.  In fact, MyProxy always
> checks to make sure there is some access control on a credential -- it will
> refuse to create a proxy for the credential otherwise.
>

I think storing unencrypted credentials in a GAMA server may not be safe 
enough. Though I believe GAMA server provides strict security protection, 
imagine a hacker can use anyone's credential once (s)he gets control of 
the GAMA server. I think an encrypted credential would ease the user a 
little bit in that case.

If the user changes the LDAP password, we can let LDAP notify the GAMA 
server. Then GAMA server can access LDAP to retrieve the old and new 
password, use old password to unencrypt the credential, and re-encrypt the 
credential with the new password. Some changes are needed to either GAMA 
server and LDAP.

>> Here is just rough though, any comment and suggestion we be appreciated.
>>
>> Jing
>>
>> Jing Tao
>> National Center for Ecological
>> Analysis and Synthesis (NCEAS)
>> 735 State St. Suite 204
>> Santa Barbara, CA 93101
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>


Zhijie Guan

San Diego Supercomputer Center