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

Mon Aug 29 08:33:52 PDT 2005

Hi Peter,

Group access can be specified by using an LDAP group in EML access
control rules.  We use it frequently.  The GAMA server also provides
CAS, which is another approach to role-based access -- I'd have to look
into how it works to provide more detail.  Regardless, I'm committed to
providing group-based ACLs as they seem critical.

We already support scaling to many LDAP servers (currently NCEAS, LTER,
PISCO, PISCO2, KNP, and others).  We also plan on adding in a
failover/load-balancing system this fall where LDAP data is replicated
in geographically dispersed locations with failover enabled.

Matt

Peter McCartney wrote:
> forgive my lack of technical expertise here, but there are a couple functional 
> points regarding this issue that I'd like to make. Maybe they arent issues at 
> all. 
> 
> first, i think we should be prepared for a large number of LDAP user 
> registries to be used in the system. if you can scale to two, it seems like 
> you should be prepared to scale to any number
> 
> Second, most data owners will want to set access control by groups, rather 
> than by individual accounts. lets say im running a cross site water nitrogen 
> sampling project involving 4 LTER sites, a national lab, and some people from 
> USGS.  i want to restrict access to the data to members of that project, plus 
> some grad students and post docs that have asked permission to use the data. 
> Id like to do this by defining a group and setting access to the group. Will 
> the solutions we are talking about let me store a group definition and its 
> members (which might have accounts in several different LDAPs, or is that yet 
> another piece of the system that will have to be added in?
> On Friday 26 August 2005 04:43 pm, Zhijie Guan wrote:
> 
>>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
>>_______________________________________________
>>Seek-dev mailing list
>>Seek-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
> 
> 

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