Hi Andy,

I understand. My goal would be to support exactly the example stated in the documentation:

= atlprod o: atlas g: /atlas r: production

Seeing how vomxsrd seems to work, to do that, the triplets would have to be checked (i.e. not multi-valued fields, but a series of triplets).

A real life example which should work (as you can see from the first post in this issue) would be:

secgsiVOMS_Fun:  ---> group: '/atlas', role: 'production', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas', role: 'NULL', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas/lcg1', role: 'NULL', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas/usatlas', role: 'NULL', cap: 'NULL'

This would result (if I parse the vomsxrd code correctly) in:
vo: atlas atlas atlas atlas
group: /atlas /atlas /atlas/lcg1 /atlas/usatlas
role: producton NULL NULL NULL
So for correct behaviour, the authorization code would have to go through these triplets in order - in other words, it is important that the production role belongs to group /atlas and VO atlas, and not to any of the other groups.

A real life example which is broken right now (I think) is:

attribute : /atlas/de/Role=production/Capability=NULL
attribute : /atlas/de/Role=NULL/Capability=NULL
attribute : /atlas/Role=NULL/Capability=NULL

This proxy must not match:

= atlprod o: atlas g: /atlas r: production

since it only has the production role for the "smaller" subgroup /atlas/de, but not for full /atlas.

Cheers,
Oliver

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

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