Hi I start with the Database schema itself. mysql> desc vo; +-------+-----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-----------+------+-----+---------+-------+ | vo | char(255) | | PRI | | | +-------+-----------+------+-----+---------+-------+ 1 row in set (0.02 sec) Vo represents the valid vo names that the admins can associate the user with. Vo field cannot be null but it can have a vo called NULL and it should for the reasons mentioned later mysql> desc admin; +-----------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+---------------+------+-----+---------+-------+ | dn | char(255) | YES | | NULL | | | prin | char(255) | YES | | NULL | | | vo | char(255) | | | all | | | rights | char(255) | YES | | | | | changedAt | timestamp(14) | YES | | NULL | | +-----------+---------------+------+-----+---------+-------+ 5 rows in set (0.00 sec) Dn or Prin can be NULL but not both together for one tuple. There should be a single Dn or Prin per Vo. Further Vo field cannot be null and the dafault Vo is all mysql> desc user; +----------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+---------------+------+-----+---------+-------+ | vo | char(255) | YES | | NULL | | | dn | char(255) | | PRI | | | | prin | char(255) | YES | | NULL | | | status | enum('Y','N') | | | Y | | | changeAt | timestamp(14) | YES | | NULL | | +----------+---------------+------+-----+---------+-------+ 5 rows in set (0.00 sec) Vo or Prin can be null for a single user but not both together. There can be multiple vo or multiple Prins per single user. Dn field cannot be null. mysql> select * from vo; +------+ | vo | +------+ | abc | | as | | dsf | | hj | | jj | | NULL | | qa | | rr | | uuu | | www | +------+ 10 rows in set (0.00 sec) mysql> select * from admin; +------+-----------------+------+-----------------------------------+----------------+ | dn | prin | vo | rights | changedAt | +------+-----------------+------+-----------------------------------+----------------+ | dn | prin | abc | add,del,ls,vo | 20041115102516 | | dn | prin1 | abc | add,del,ls,vo | 20041112100109 | | dn | prin2 | abc | add,del,ls | 20041112100815 | | dn3 | prin3 | abc3 | add,del,ls,prin | 20041112102104 | | dn4 | prin4 | abc4 | add,del,ls,prin,vo,enable,disable | 20041112105928 | | dn4 | prin4 | as | add,del,ls,prin,vo,enable,disable | 20041112110304 | | dn4 | prin4 | www | add,del,ls,prin,vo,enable,disable | 20041112110321 | | dn4 | sekhri@FNAL.GOV | abc | add,del,vo,prin | 20041115150603 | | dn4 | sekhri@FNAL.GOV | all | add,del,ls,vo,disable,enable,prin | 20041115133154 | | dn4 | sekhri@FNAL.GOV | qqq | add,del,ls,prin,enable,disable | 20041117103045 | | dn4 | sekhri@FNAL.GOV | ttt | add,del,vo,ls,enable,disable | 20041117103058 | +------+-----------------+------+-----------------------------------+----------------+ Rights fields should have the following format add,del,ls,prin,vo,enable,disable It should not have any other string in it,although haveing it by mistake doesnot clobber the logic. Fo r example having lsa in it will just be ignored by the code add/del means that this admin (known by Dn or Prin) can add or del a certain DN Now this doesnot really means that the amdin is adding or deleting the user from the User table actually if the user is already present there. It just means that he is assocating or deassociating his Vo or Prin with that user. Examples later in the document enable/disable means that this admin (known by Dn or Prin) can set status if the DN to Y or N only if he has enable or disable rights for a ceratin VO ls means that this admin (known by Dn or Prin) can list the members from user table only if he has ls right for a ceratin VO. vo means that this admin (known by Dn or Prin) can associate certain vo with the member prin means that this admin (known by Dn or Prin) can associate certain prin with the member mysql> select * from user; +-----------+------+-------------------------------+--------+----------------+ | vo | dn | prin | status | changeAt | +-----------+------+-------------------------------+--------+----------------+ | jj | df | gh,kk,vv,hh | Y | 20041116113917 | | abc | qw | qw | N | 20041115150523 | | rr,abc | aa | zz,tt | Y | 20041116113917 | | uuu,www | yyy | ttt,qqq,iii | Y | 20041116114811 | | qa | as | qq,gh,we,sa,ll,love,ooo | Y | 20041116113917 | | as,hj,dsf | we | rt,as,ll,nn,ij,kk,fgh | Y | 20041116113917 | | NULL | www | abc | N | 20041115133443 | | abc | qwr | nnn,kkk,ooo | N | 20041116114015 | | abc | % | new,abc,nnn,sekhri@FNAL.GOV | N | 20041116131432 | | abc | null | abc | Y | 20041116115227 | | www,rr | ppp | NULL | Y | 20041116114901 | | www | abc | sekhri@FNAL.GOV,neha@FNAL.GOV | Y | 20041116141502 | | NULL | xyz | sekhri@FNAL.GOV,neha@FNAL.GOV | Y | 20041116131834 | | NULL | bbb | neha@FNAL.GOV | Y | 20041116141654 | +-----------+------+-------------------------------+--------+----------------+ ------------------------------------------------------------------------------------------------- Lets take the UserInterface first A normal user is allowed only to add/del or ls his DNs associated with his principal only For example UserInterface-->add abc User already present in DB. Associated principal neha@FNAL.GOV,sekhri@FNAL.GOV with user succesfully This would try to add a member with dn abc and associate the principal of this user with him. If the member already exist, then this would just append user principal with the member prin list To see if the member is added succesfully one could do ls again UserInterface-->ls ********************************** vo--> www dn--> abc prin--> neha@FNAL.GOV,sekhri@FNAL.GOV status--> Y ********************************** Since the member existed already , the user prin sekhri@FNAL.GOV is appended to the prin list Issuing the same add command would not change anything UserInterface-->add abc User already present in DB. The same thing appies with del UserInterface-->del abc The associated vo with user is unaffected Associated principal neha@FNAL.GOV with user succesfully UserInterface-->ls This really didnot deleted the member from the user table in SAZDB. It just removed the assocation of this user principal with the member Note that a normal user cannot assocate a Vo with the member in SAZ, Only admins can do that Note a member is deleted actually froma SAZDB only if both Vo and Prin are reduced to NULL. That means the last person left assocaited with the member can actually delete the record from SAZDB. Further is there still exists a valid VO but there is no Principal letf to be assocated with the user then the principal is associated with NULL and the same thing applies to VO. ------------------------------------------------------------------------------------------------- Now lets take AdminInterface If the admin issues a ls command with wildcard * or null for vo dn and prin then all the member for various VOs will be listed if that admin has ls right for that vo. An admin can have all the rights ibn a vo called "all" and achieve the same result. Even if the admin is in all vo and has all the rights , a certain Voi can override that rights for that admin For example look at the output the admin get when he issues AdminInterface-->ls or AdminInterface-->ls % % % or AdminInterface-->ls % null null ---------------------Virtual Organisation--------------------- abc You don't have ls right for vo abc ---------------------Virtual Organisation--------------------- as ********************************** vo--> as,hj,dsf dn--> we prin--> rt,as,ll,nn,ij,kk,fgh status--> Y ********************************** ---------------------Virtual Organisation--------------------- dsf ********************************** vo--> as,hj,dsf dn--> we prin--> rt,as,ll,nn,ij,kk,fgh status--> Y ********************************** ---------------------Virtual Organisation--------------------- hj ********************************** vo--> as,hj,dsf dn--> we prin--> rt,as,ll,nn,ij,kk,fgh status--> Y ********************************** ---------------------Virtual Organisation--------------------- jj ********************************** vo--> jj dn--> df prin--> gh,kk,vv,hh status--> Y ********************************** ---------------------Virtual Organisation--------------------- NULL ********************************** vo--> NULL dn--> www prin--> abc status--> N ********************************** ********************************** vo--> NULL dn--> xyz prin--> neha@FNAL.GOV status--> Y ********************************** ********************************** vo--> NULL dn--> bbb prin--> neha@FNAL.GOV status--> Y ********************************** ---------------------Virtual Organisation--------------------- qa ********************************** vo--> qa dn--> as prin--> qq,gh,we,sa,ll,love,ooo,% status--> Y ********************************** ---------------------Virtual Organisation--------------------- rr ********************************** vo--> rr,abc dn--> aa prin--> zz,tt status--> Y ********************************** ********************************** vo--> www,rr dn--> ppp prin--> NULL status--> Y ********************************** ---------------------Virtual Organisation--------------------- uuu ********************************** vo--> uuu,www dn--> yyy prin--> ttt,qqq,iii status--> Y ********************************** ---------------------Virtual Organisation--------------------- www ********************************** vo--> www dn--> prin--> status--> Y ********************************** ********************************** vo--> uuu,www dn--> yyy prin--> ttt,qqq,iii status--> Y ********************************** ********************************** vo--> www,rr dn--> ppp prin--> NULL status--> Y ********************************** ********************************** vo--> www dn--> abc prin--> neha@FNAL.GOV status--> Y ********************************** If you look in the admin table for admin sekhri@FNAL.GOV amd VO abc , then you will see that this admin doesnot have ls rights for this vo . Although this admin is in the "all" vo and have all thr rights. This means a certain Vo can override the admin rights from all vo. Note that there is a vo called NULL and the reason why its there, is beacuse a member can be given the liberty to not to be associated with any vo but still be in SAZDB but associated with just a principal. In this case the VO association of that member will be NULL. So its imperative that the vo table should have NULL as one of the VO always. Now lets try the add command with admin interface AdminInterface-->add abc % % DN cannot be % for operation add First of all you cannot have null or % fro dn when using add or del command. The basic functionality of add/del is the same as in case of user with the exception that here the admin can also associate vo with the member. AdminInterface-->add abc xyz null User already present in DB. Associated vo abc with user succesfully AdminInterface-->ls abc % % You don't have ls right for vo abc AdminInterface-->add as xyz null User already present in DB. Associated vo abc,as with user succesfully AdminInterface-->ls as % % ********************************** vo--> as,hj,dsf dn--> we prin--> rt,as,ll,nn,ij,kk,fgh status--> Y ********************************** ********************************** vo--> abc,as dn--> xyz prin--> neha@FNAL.GOV status--> Y ********************************** Now when the admin tried to add the member xyz with vo abc he was able to assicate hos vo with that member but he was not able to list the members from vo abc since he did not had ls right for that vo Now he tried to add the member xyz with his vo as and he was able to list it also. Now he can see member is associated with as correctly or not by issuing ls command Now lets try to add a member with a vo and prin for which this admin doesnot have vo right AdminInterface-->add qqq xyz ppp You don't have vo altering right Now lets try to add a member with a vo and prin for which this admin doesnot have prin right AdminInterface-->add ttt xyz ppp Warning: Admin cannot assign pricipal. Setting principal to null User already present in DB. Associated vo abc,as,ttt with user succesfully AdminInterface-->ls ttt % % ********************************** vo--> abc,as,ttt dn--> xyz prin--> neha@FNAL.GOV status--> Y ********************************** Notice that the admins issued principal is automatically set to null and his vo is just associated with the member Now if the admin wants to associate a certina prin with this memeber he has to come from vo which has prin right for him AdminInterface-->add null xyz ppp User already present in DB. Associated principal neha@FNAL.GOV,ppp with user succesfully AdminInterface-->ls ttt % % ********************************** vo--> abc,as,ttt dn--> xyz prin--> neha@FNAL.GOV,ppp status--> Y ********************************** Since the admin had null for vo , he is checked against all vo and since he has prin right he is able to associate the principal ppp with member xyz Finally lets try the enable and disable command. Please note that it works in the same way as ls command and you can specify wildcard null % for vo dn and prin. Ofcourse there needs to be enable disable right for each vo the admin is trying to change the status. AdminInterface-->enable ttt % % User xyz status changed succesfully. AdminInterface-->enable ttt % % User xyz status is set to Y in DB already AdminInterface-->enable % % % ---------------------Virtual Organisation--------------------- abc You don't have enable right for vo abc ---------------------Virtual Organisation--------------------- as User we status is set to Y in DB already User xyz status is set to Y in DB already ---------------------Virtual Organisation--------------------- dsf User we status is set to Y in DB already ---------------------Virtual Organisation--------------------- hj User we status is set to Y in DB already ---------------------Virtual Organisation--------------------- jj User df status is set to Y in DB already ---------------------Virtual Organisation--------------------- NULL User www status changed succesfully. User bbb status is set to Y in DB already ---------------------Virtual Organisation--------------------- qa User as status is set to Y in DB already ---------------------Virtual Organisation--------------------- rr User aa status is set to Y in DB already User ppp status is set to Y in DB already ---------------------Virtual Organisation--------------------- uuu User yyy status is set to Y in DB already ---------------------Virtual Organisation--------------------- www User status is set to Y in DB already User yyy status is set to Y in DB already User ppp status is set to Y in DB already User abc status is set to Y in DB already AdminInterface-->disable hj % % User we status changed succesfully. AdminInterface-->ls hj % % ********************************** vo--> as,hj,dsf dn--> we prin--> rt,as,ll,nn,ij,kk,fgh status--> N ********************************** ------------------------------------------------------------------------------------------------- This version has an updated Java client to test SAZserver. It doesnot require Globus to work. To test the Java client one has to issue a command sazjclient ... Here is an example sazjclient sazc.conf /tmp/x509up_u500 /home/sekhri/.globus/usercert.pem /etc/grid-security/certificates/1c3f2ca8.0 onnecting to Host:venom.fnal.gov Port:8888 Message from server *yes* Association VO=NULL PRIN=NULL The C Client on the other hnad works quite the same Please note that the C client requires Globus libs to function properly sazclient -file ... Here is an example sazclient -file sazc.conf /tmp/x509up_u500 /home/sekhri/.globus/usercert.pem /etc/grid-security/certificates/1c3f2ca8.0 ending request to SAZ server host : venom.fnal.gov port : 8888 identity: /DC=org/DC=doegrids/OU=Services/CN=venom.fnal.gov Data from server is *yes* The Association : VO=NULL PRIN=NULL ------------------------------------------------------------------------------------------------- This version also has and option PERMITTED_PRINCIPAL_DOMAIN in the conf file saz.conf which allows only certain Kerberos domains to connect to AIServer