[kepler-dev] GAMA server for SEEK
bbaker at ncsa.uiuc.edu
Fri Aug 26 12:10:46 PDT 2005
A few notes below.
At 12:34 2005-08-26, Jing Tao wrote:
>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
>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.
>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.
>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.
>Here is just rough though, any comment and suggestion we be appreciated.
>National Center for Ecological
>Analysis and Synthesis (NCEAS)
>735 State St. Suite 204
>Santa Barbara, CA 93101
More information about the Kepler-dev