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

Mon Aug 29 12:45:12 PDT 2005

Again, bear with me if im naïve - we're only starting to learn LDAP here. Lets say I have an LDAP system (lets say ASU for now) that I have the ability to define groups and that contains user accounts of people I want to add to those groups. I put that groups dn into my eml dataset ACL. That much seems pretty clear as its all within one LDAP. Now I'd like to grant access to several other people that have accounts in the NCEAS LDAP. Do I have to add those names individually to my EML access list, or would I be able to add their NCEAS accounts to my ASU LDAP group definition and count on a portal knowing where to go to authenticate the user according to their full dn info?

It seems fairly straight-froward to grant access to a local group and also to another group defined in another LDAP (lets say kepler) where I don't have control that membership but anybody's membership in that group entitles them access to my resource. But I can also see lots of cases where that approach would not be secure enough and something where I could control the group but reference foreign accounts would be much better. 

Peter McCartney(peter.mccartney at asu.edu)
International Institute for Sustainability
Arizona State University
480-965-6791

> -----Original Message-----
> From: Matt Jones [mailto:jones at nceas.ucsb.edu] 
> Sent: Monday, August 29, 2005 8:34 AM
> To: Peter McCartney
> Cc: seek-dev at ecoinformatics.org
> Subject: Re: [seek-dev] [kepler-dev] GAMA server for SEEK
> 
> 
> 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/listin
fo/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
-------------------------------------------------------------------