Hi Gerri,
It seems libXrdSecgsiVOMS.so already fill out the XrdSecEntity with group info and I can just use that in oss.authdb file? Here is what I am doing:
xrootd.seclib /.../libXrdSec.so
sec.protparm gsi -vomsfun:/.../libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|dbg|vos=atlas|grps=/atlas
sec.protocol /... gsi -ca:1 -crl:3
This enforce "atlas" as vo and "/atlas" as group. Unless these two are satisfied, nothing will be filled into XrdSecEntity.grps
And in oss.authdb file, I have
g /atlas /path rl
(The "/atlas" is to be matched by group filled by libXrdSecgsiVOMS.so )
Do I understand this correctly? Do I still need to use AuthzVO ?
regards,
Wei Yang | [log in to unmask] | 650-926-3338(O)
On Feb 6, 2013, at 4:46 PM, Gerardo Ganis wrote:
>
> Of course, sorry. I thought that Wei was aware of that, since I
> believe he used it so far.
> With the default settings, the new plug-in should fill XrdSecEntity
> exactly as the 'handmade' VOMS extractor
> was doing. So authorization via AuthzVOMS should just work as before.
>
> Gerri
>
>
> On 2/6/13 7:33 PM, Andrew Hanushevsky wrote:
>> The third option is to use teh AuthZVOMS plugin which will do exactly
>> what you want it to do and more.
>>
>> Andy
>>
>> On Wed, 6 Feb 2013, Gerardo Ganis wrote:
>>
>>> Hi Wei,
>>>
>>> Thanks for the feedback.
>>>
>>> About your question.
>>> The module fills the XrdSecEntity structure which is the analysed
>>> by the authorization module.
>>>
>>> Another option is to specify the group (or groups) you want to
>>> authorize with the 'grps=grp1[,grp2,...]'
>>> configuration option: if the group is not found, authentication
>>> fails. This functionality was not correctly
>>> implemented in the binary you tested, but I have just fixed it, so
>>> you can try it now taking the latest
>>> version.
>>>
>>> Cheers, Gerri
>>>
>>>
>>> On 2/6/13 8:53 AM, Yang, Wei wrote:
>>>> Hi Gerri,
>>>>
>>>> It turns out that the .so I tried wasn't the latest. I just tried
>>>> the latest one (slc5-gcc4.3) and it can extract the VO info
>>>> correctly from various types of limited proxy used at ATLAS sites. I
>>>> will try again with slc5-gcc4.1 and slc6 platforms. I have another
>>>> question. With this module, how to do map a VO to a specific group
>>>> (and then grant this group access in oss.authdb)?
>>>>
>>>> regards,
>>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 5, 2013, at 1:21 AM, Gerardo Ganis wrote:
>>>>
>>>>> Hi Wei,
>>>>>
>>>>> It does not look as loading the right plug-in .
>>>>> Are there any related messages at xrootd startup?
>>>>> Could you post the full startup log?
>>>>>
>>>>> You should get something like this at a certain point:
>>>>>
>>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: ++++++++++++++++++ VOMS
>>>>> plugi-in ++++++++++++++++++++++++++++++
>>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: +++ proxy fmt: raw
>>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: +++ group option: last of
>>>>> all
>>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit:
>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 130205 10:20:13 4689 secgsi_LoadVOMSFun: using 'XrdSecgsiVOMSFun()'
>>>>> from
>>>>> libXrdSecgsiVOMS.so
>>>>> =====> sec.protocol gsi -cert:~/.globus/usercert.pem
>>>>> -key:~/.globus/userkey.pem
>>>>> -certdir:/afs/cern.ch/user/g/ganis/.globus/certificates -ca:2 -crl:3
>>>>> -crldir:/afs/cern.ch/user/g/ganis/.globus/certificates
>>>>> Config 2 authentication directives processed in xrd.voms.cf
>>>>> ------ Authentication system initialization completed.
>>>>>
>>>>> Gerri
>>>>>
>>>>>
>>>>> On 2/4/13 8:15 PM, Yang, Wei wrote:
>>>>>> [Adding David Smith since he may want to know this ...]
>>>>>>
>>>>>> Hi Gerri,
>>>>>>
>>>>>> I am having trouble getting it to work. On RHEL5-64, I compiled
>>>>>> xrootd git head with gcc 4.3 and use the .so you compiled. Here is
>>>>>> my config file:
>>>>>>
>>>>>> all.export /xrootd/atlas r/o
>>>>>> all.role server
>>>>>> xrootd.async off
>>>>>> xrootd.seclib
>>>>>> /afs/slac.stanford.edu/package/xrootd/githead/amd64_rhel50/src/libXrdSec.so
>>>>>> sec.protparm gsi -vomsfun:/etc/xrootd/libXrdSecgsiVOMS.so.1
>>>>>> -vomsfunparms:grpopt=0|certfmt=raw|vos=atlas|dbg
>>>>>> sec.protocol
>>>>>> /afs/slac.stanford.edu/package/xrootd/githead/amd64_rhel50/src gsi
>>>>>> -ca:1 -crl:3
>>>>>> acc.authdb /etc/xrootd/auth_file
>>>>>> acc.authrefresh 60
>>>>>> ofs.authorize
>>>>>>
>>>>>> here is my proxy info (I tried a proxy created locally using VOMS
>>>>>> 1.8.8 and a proxy created at CERN using VOMS 2.0.8).
>>>>>>
>>>>>> subject : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy
>>>>>> issuer : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>>> identity : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>>> type : proxy
>>>>>> strength : 1024 bits
>>>>>> path : /tmp/x509up_u2353
>>>>>> timeleft : 11:58:22
>>>>>> === VO atlas extension information ===
>>>>>> VO : atlas
>>>>>> subject : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>>> issuer : /DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch
>>>>>> attribute : /atlas/Role=NULL/Capability=NULL
>>>>>> attribute : /atlas/lcg1/Role=NULL/Capability=NULL
>>>>>> attribute : /atlas/usatlas/Role=NULL/Capability=NULL
>>>>>> attribute : nickname = yangw (atlas)
>>>>>> timeleft : 11:58:22
>>>>>> uri : lcg-voms.cern.ch:15001
>>>>>>
>>>>>> Here is the $X509_VOMS_DIR
>>>>>>
>>>>>> [yangw@atl-prod08 xrootd]$ ls -l $X509_VOMS_DIR
>>>>>> total 68
>>>>>> -rw-r--r-- 1 yangw sf 69 Feb 16 2010 README
>>>>>> drwxr-xr-x 2 yangw sf 2048 Nov 25 2011 atlas/
>>>>>> -rw-r--r-- 1 yangw sf 1440 Feb 2 2010 cert-voms-01.cnaf.infn.it.pem
>>>>>> -rw-r--r-- 1 yangw sf 1440 Feb 2 2010
>>>>>> cert-voms-01.cnaf.infn.it.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010
>>>>>> cert-voms-01.cnaf.infn.it.pem.2
>>>>>> -rw-r--r-- 1 yangw sf 1436 Feb 2 2010 grid12.lal.in2p3.fr.pem
>>>>>> -rw-r--r-- 1 yangw sf 5154 Feb 2 2010 mu4.matrix.sara.nl.pem
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-01.pd.infn.it.pem
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-01.pd.infn.it.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1420 Feb 2 2010 voms-01.pd.infn.it.pem.2
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-02.pd.infn.it.pem
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-02.pd.infn.it.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1420 Feb 2 2010 voms-02.pd.infn.it.pem.2
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem.2
>>>>>> -rw-r--r-- 1 yangw sf 1399 Feb 2 2010 voms.cnaf.infn.it.pem.3
>>>>>> -rw-r--r-- 1 yangw sf 1484 Feb 2 2010 voms.fnal.gov.pem
>>>>>> -rw-r--r-- 1 yangw sf 1298 Feb 2 2010 voms.fnal.gov.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1651 Feb 2 2010 voms.grid.sara.nl.pem
>>>>>> -rw-r--r-- 1 yangw sf 5152 Feb 2 2010 voms.grid.sara.nl.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1793 Feb 2 2010 voms.grid.sinica.edu.tw.pem
>>>>>> -rw-r--r-- 1 yangw sf 1842 Feb 2 2010 voms.gridpp.ac.uk.pem
>>>>>> -rw-r--r-- 1 yangw sf 1843 Feb 2 2010 voms.gridpp.ac.uk.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 2138 Feb 2 2010 voms.gridpp.ac.uk.pem.2
>>>>>> -rw-r--r-- 1 yangw sf 1472 Feb 2 2010
>>>>>> voms.research-infrastructures.eu.pem
>>>>>> -rw-r--r-- 1 yangw sf 1472 Feb 2 2010
>>>>>> voms.research-infrastructures.eu.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010 voms2.cnaf.infn.it.pem
>>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010 voms2.cnaf.infn.it.pem.1
>>>>>> -rw-r--r-- 1 yangw sf 1404 Feb 2 2010 voms2.cnaf.infn.it.pem.2
>>>>>>
>>>>>> And here is the log file:
>>>>>>
>>>>>> X509Chain::Dump://------------------Dumping X509 chain content
>>>>>> ------------------//
>>>>>> X509Chain::Dump://
>>>>>> X509Chain::Dump:// Chain instance: 0x8eeb7d0
>>>>>> X509Chain::Dump://
>>>>>> X509Chain::Dump:// Number of certificates: 3
>>>>>> X509Chain::Dump://
>>>>>> X509Chain::Dump:// CA: /DC=org/DC=DOEGrids/OU=Certificate
>>>>>> Authorities/CN=DOEGrids CA 1
>>>>>> X509Chain::Dump:// EEC: /DC=org/DC=doegrids/OU=People/CN=Wei Yang
>>>>>> 74203
>>>>>> X509Chain::Dump://
>>>>>> X509Chain::Dump:// Issuer: d1b603c3.0 Subject: 1c3f2ca8.0 Type: CA
>>>>>> X509Chain::Dump:// Issuer: 1c3f2ca8.0 Subject: 684536c7.0 Type: EEC
>>>>>> X509Chain::Dump:// Issuer: 684536c7.0 Subject: f81adb11.0 Type: Proxy
>>>>>> X509Chain::Dump://
>>>>>> X509Chain::Dump://---------------------------- END
>>>>>> ------------------------------//
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +++++++++++++++ X509 dump
>>>>>> +++++++++++++++++++++++
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + File:
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Type: Proxy
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Serial Number: 283485584
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Subject:
>>>>>> /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Subject hash: f81adb11.0
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Issuer:
>>>>>> /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Issuer hash: 684536c7.0
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Validity:
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + NotBefore: 1360032944
>>>>>> UTC - Mon Feb 4 18:55:44 2013
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + NotAfter: 1360076444
>>>>>> UTC - Tue Feb 5 07:00:44 2013
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + PKI: Public
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>>> 130204 11:02:36 14262 crypto_X509::Dump:
>>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: xrc: 1
>>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: NOT OK: Cannot discover
>>>>>> holder from certificate chain!
>>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: WARNING: no VO found! (VOMS
>>>>>> attributes: '')
>>>>>> 130204 11:02:36 14262 XrootdXeq: yangw.27906:22@atlint01 login as
>>>>>> 684536c7.0
>>>>>> 130204 11:02:41 14262 XrootdXeq: yangw.27906:22@atlint01 disc 0:00:05
>>>>>>
>>>>>> I am not sure what the 4th line from the bottom mean.
>>>>>>
>>>>>> regards,
>>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>>>>
>>>>>>
>>>>>> On Feb 4, 2013, at 9:42 AM, Gerardo Ganis wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is the status of things:
>>>>>>>
>>>>>>> The plug-in is available for test at
>>>>>>> 'https://github.com/gganis/voms.git' from where you can download
>>>>>>> the sources. Binaries for SLC5 (x86_64, gcc-4.1, gcc 4.3) and
>>>>>>> SLC6
>>>>>>> (x86_64, gcc-4.6) are available under
>>>>>>>
>>>>>>> /afs/cern.ch/work/g/ganis/public/vomsxrd/vomsxrd-0.0.1
>>>>>>>
>>>>>>> (README and examples under
>>>>>>> /afs/cern.ch/work/g/ganis/public/vomsxrd).
>>>>>>>
>>>>>>> With the following caveats:
>>>>>>>
>>>>>>> 1. The builds require VOMS 2.0.8 which, if I understand
>>>>>>> correctly, is a not (yet?) available in OSG
>>>>>>> 2. Unfortunately the backport of the vomsfun functionality
>>>>>>> was
>>>>>>> not complete in the 3.2.x stable branch,
>>>>>>> so to use the plug-in you have either to use the HEAD
>>>>>>> of the
>>>>>>> 'stable' branch or 3.3.x-rc1 .
>>>>>>> RPMs for the stable branch are available from the
>>>>>>> Teamcity
>>>>>>> portal:
>>>>>>>
>>>>>>> https://teamcity-dss.cern.ch:8443/project.html?projectId=project13&tab=projectOverview
>>>>>>>
>>>>>>>
>>>>>>> Can you please let me know if you can try this out or what
>>>>>>> you miss
>>>>>>> to be able to try?
>>>>>>>
>>>>>>> Gerri
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/31/13 7:19 PM, Yang, Wei wrote:
>>>>>>>> I haven't get it to work yet. I am communicating with the
>>>>>>>> developer.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 31, 2013, at 2:28 AM, Tommaso Boccali wrote:
>>>>>>>>
>>>>>>>>> Follow-up Comment #2, sr #135141 (project xrootd):
>>>>>>>>>
>>>>>>>>> ciao, news on that plugin?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>>
>>>>>>>>> tom
>>>>>>>>>
>>>>>>>>> _______________________________________________________
>>>>>>>>>
>>>>>>>>> Reply to this item at:
>>>>>>>>>
>>>>>>>>> <http://savannah.cern.ch/support/?135141>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Message sent via/by LCG Savannah
>>>>>>>>> http://savannah.cern.ch/
>>>>>>>>>
>>>>>>> --
>>>>>>> +--------------------------------------------------------------------------+
>>>>>>>
>>>>>>> Gerardo GANIS CERN, PH Dept, SFT group, CH 1211 Geneve 23
>>>>>>> room: 32-RC-006, tel: +41 22 7676439
>>>>>>> email: [log in to unmask], fax: +41 22
>>>>>>> 7669133
>>>>>>> +--------------------------------------------------------------------------+
>>>>>>>
>>>>>>>
>>>
>>> ########################################################################
>>> Use REPLY-ALL to reply to list
>>>
>>> To unsubscribe from the XROOTD-DEV list, click the following link:
>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|