I think LCMAPS is probably a good approach for sites that already deployed Grid middleware. It provides a consistent and familiar interface to site admins. In data transfer use case, the overhead of LCMAPS is also acceptable - we have used it with SRM and GridFTP for years. One question for LCMAPS is whether it is used in EU or not.
<br>

<br>
Having said that, there are cases that we want something light weight such as VOMSXRD or XrdHTTPVOMS. One question is that we normally have several VOMS attribute attached to a proxy, like this:
<br>

<br>
subject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=yangw/CN=667097/CN=Wei Yang
<br>
issuer    : /DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch
<br>
attribute : /atlas/Role=production/Capability=NULL
<br>
attribute : /atlas/Role=NULL/Capability=NULL
<br>
attribute : /atlas/lcg1/Role=NULL/Capability=NULL
<br>
attribute : /atlas/usatlas/Role=NULL/Capability=NULL
<br>
attribute : nickname = yangw (atlas)
<br>

<br>

<br>

<br>
I _think_ when we initiate the proxy, we can control which one is first in the list of attributes. So we can either take all attributes (if we figure out how), or the first one (or last one), similar to what VOMSXRD does.
<br>

<br>
I think something like &quot;grps: &#39;/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL’” is the cleanest. People can tell immediately who gets what in authdb. Q: Can the NULL items be ignored? How do we handle those spaces in authdb?
<br>

<br>
regards,
<br>
--
<br>
Wei Yang  |  <a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>  |  650-926-3338(O)  
<br>

<br>

<br>

<br>

<br>

<br>

<br>
From:  Fabrizio Furano &lt;<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>&gt;
<br>
Reply-To:  xrootd/xrootd &lt;<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>&gt;
<br>
Date:  Thursday, August 31, 2017 at 8:37 AM
<br>
To:  xrootd/xrootd &lt;<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>&gt;
<br>
Cc:  Subscribed &lt;<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>&gt;
<br>
Subject:  Re: [xrootd/xrootd] secxtractor attributes not used for authentication (#566)
<br>

<br>

<br>
Hi,
<br>

<br>
FYI, we will push a new release of XrdHttpVOMS (0.2.5) to epel-testing in the next few days,
<br>
here&#39;s an example of the way it extracts groupnames from the primary fqan:
<br>

<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - user: &#39;/DC=ch/DC=cern/OU=Organic
<br>
Units/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano&#39;
<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - vorg: &#39;dteam&#39;
<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - fqan[0]:/dteam/Role=NULL/Capability=NULL
<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - grps: &#39;/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL&#39;
<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - role: &#39;NULL&#39;
<br>
170831 17:27:12 4327 furano.0:24@lxplus023 VOMS proxy info - name: &#39;/DC=ch/DC=cern/OU=Organic
<br>
Units/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano&#39; VO: dteam grps: &#39;/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL&#39;
<br>

<br>
Please let me know if you think that there&#39;s anything to fix for XrdAcc to treat correctly these fields.
<br>

<br>
Cheers
<br>
Fabrizio
<br>

<br>
On 08/21/2017 10:00 PM, xrootd-dev wrote:
<br>
&gt; Thank you Brian for explaining slash usage.
<br>
&gt; 
<br>
&gt; On Mon, 21 Aug 2017, Brian Bockelman wrote:
<br>
&gt; 
<br>
&gt;&gt; Looking at what I did for `XrdLcmaps`:
<br>
&gt;&gt; - *space*-separated list of groups.
<br>
&gt;&gt; - They should start with a slash; VOMS groups are hierarchical (i.e., `/atlas/foo/bar` is distinct from `/atlas/baz`) unlike
<br>
&gt; Unix groups.
<br>
&gt;&gt;
<br>
&gt;&gt; One open question is how we should handle a proxy certificate with multiple VOMS extensions present - i.e., a proxy
<br>
&gt; certificate with both ATLAS and CMS extensions. After all, it&#39;s perfectly acceptable for the CMS VOMS server to sign an
<br>
&gt; extensions with FQAN `/atlas`. It&#39;s traditional that CMS group names are prefixed with `/cms`, but not enforced or validated by
<br>
&gt; the client.
<br>
&gt;&gt;
<br>
&gt;&gt; --
<br>
&gt;&gt; You are receiving this because you commented.
<br>
&gt;&gt; Reply to this email directly or view it on GitHub:
<br>
&gt;&gt; https://github.com/xrootd/xrootd/issues/566#issuecomment-323732506
<br>
&gt;&gt;
<br>
&gt;&gt; ########################################################################
<br>
&gt;&gt; Use REPLY-ALL to reply to list
<br>
&gt;&gt;
<br>
&gt;&gt; To unsubscribe from the XROOTD-DEV list, click the following link:
<br>
&gt;&gt; https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&amp;A=1
<br>
&gt; 
<br>
&gt; —
<br>
&gt; You are receiving this because you were mentioned.
<br>
&gt; Reply to this email directly, view it on GitHub &lt;https://github.com/xrootd/xrootd/issues/566#issuecomment-323838017&gt;, or mute
<br>
&gt; the thread &lt;https://github.com/notifications/unsubscribe-auth/AFIaTwo5eEUSSlPBrtJwbPCOFLIQ-Ihxks5saeHsgaJpZM4O7mEG&gt;.
<br>
&gt; 
<br>
—
<br>
You are receiving this because you are subscribed to this thread.
<br>
Reply to this email directly, 
<br>
view it on GitHub &lt;https://github.com/xrootd/xrootd/issues/566#issuecomment-326334551&gt;, or 
<br>
mute the thread &lt;https://github.com/notifications/unsubscribe-auth/AE9TAxeOEcdB1AKP4IwI3l_TOqKEX6PYks5sdtNJgaJpZM4O7mEG&gt;.
<br>

<br>

<br>
{&quot;api_version&quot;:&quot;1.0&quot;,&quot;publisher&quot;:{&quot;api_key&quot;:&quot;05dde50f1d1a384dd78767c55493e4bb&quot;,&quot;name&quot;:&quot;GitHub&quot;},&quot;entity&quot;:{&quot;external_key&quot;:&quot;github/xrootd/xrootd&quot;,&quot;title&quot;:&quot;xrootd/xrootd&quot;,&quot;subtitle&quot;:&quot;GitHub repository&quot;,&quot;main_image_url&quot;:&quot;https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png&quot;,&quot;avatar_image_url&quot;:&quot;https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png&quot;,&quot;action&quot;:{&quot;name&quot;:&quot;Open in GitHub&quot;,&quot;url&quot;:&quot;https://github.com/xrootd/xrootd&quot;}},&quot;updates&quot;:{&quot;snippets&quot;:[{&quot;icon&quot;:&quot;PERSON&quot;,&quot;message&quot;:&quot;@ffurano in #566: Hi,\n\n FYI, we will push a new release of XrdHttpVOMS (0.2.5) to epel-testing in the next few days,\nhere&#39;s an example of the way it extracts groupnames from the primary fqan:\n\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - user: &#39;/DC=ch/DC=cern/OU=Organic\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano&#39;\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - vorg: &#39;dteam&#39;\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - fqan[0]:/dteam/Role=NULL/Capability=NULL\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - grps: &#39;/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL&#39;\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - role: &#39;NULL&#39;\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS proxy info - name: &#39;/DC=ch/DC=cern/OU=Organic\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano&#39; VO: dteam grps: &#39;/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL&#39;\n\n Please let me know if you think that there&#39;s anything to fix for XrdAcc to treat correctly these fields.\n\nCheers\nFabrizio\n\nOn 08/21/2017 10:00 PM, xrootd-dev wrote:\n\u003e Thank you Brian for explaining slash usage.\n\u003e \n\u003e On Mon, 21 Aug 2017, Brian Bockelman wrote:\n\u003e \n\u003e\u003e Looking at what I did for `XrdLcmaps`:\n\u003e\u003e - *space*-separated list of groups.\n\u003e\u003e - They should start with a slash; VOMS groups are hierarchical (i.e., `/atlas/foo/bar` is distinct from `/atlas/baz`) unlike\n\u003e Unix groups.\n\u003e\u003e\n\u003e\u003e One open question is how we should handle a proxy certificate with multiple VOMS extensions present - i.e., a proxy\n\u003e certificate with both ATLAS and CMS extensions. After all, it&#39;s perfectly acceptable for the CMS VOMS server to sign an\n\u003e extensions with FQAN `/atlas`. It&#39;s traditional that CMS group names are prefixed with `/cms`, but not enforced or validated by\n\u003e the client.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e You are receiving this because you commented.\n\u003e\u003e Reply to this email directly or view it on GitHub:\n\u003e\u003e https://github.com/xrootd/xrootd/issues/566#issuecomment-323732506\n\u003e\u003e\n\u003e\u003e ########################################################################\n\u003e\u003e Use REPLY-ALL to reply to list\n\u003e\u003e\n\u003e\u003e To unsubscribe from the XROOTD-DEV list, click the following link:\n\u003e\u003e https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV\u0026A=1\n\u003e \n\u003e —\n\u003e You are receiving this because you were mentioned.\n\u003e Reply to this email directly, view it on GitHub \u003chttps://github.com/xrootd/xrootd/issues/566#issuecomment-323838017\u003e, or mute\n\u003e the thread \u003chttps://github.com/notifications/unsubscribe-auth/AFIaTwo5eEUSSlPBrtJwbPCOFLIQ-Ihxks5saeHsgaJpZM4O7mEG\u003e.\n\u003e \n&quot;}],&quot;action&quot;:{&quot;name&quot;:&quot;View Issue&quot;,&quot;url&quot;:&quot;https://github.com/xrootd/xrootd/issues/566#issuecomment-326334551&quot;}}}
<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you commented.<br />Reply to this email directly, <a href="https://github.com/xrootd/xrootd/issues/566#issuecomment-326359438">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AD7YjleoxJsv7GneA2r7xDLbxqf0VJObks5sducNgaJpZM4O7mEG">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AD7YjvIf43DwD1YZ8S5qNVF3-o7KViWlks5sducNgaJpZM4O7mEG.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/xrootd/xrootd/issues/566#issuecomment-326359438"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<!cript type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@wyang007 in #566: I think LCMAPS is probably a good approach for sites that already deployed Grid middleware. It provides a consistent and familiar interface to site admins. In data transfer use case, the overhead of LCMAPS is also acceptable - we have used it with SRM and GridFTP for years. One question for LCMAPS is whether it is used in EU or not.\r\n\r\nHaving said that, there are cases that we want something light weight such as VOMSXRD or XrdHTTPVOMS. One question is that we normally have several VOMS attribute attached to a proxy, like this:\r\n\r\nsubject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=yangw/CN=667097/CN=Wei Yang\r\nissuer    : /DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch\r\nattribute : /atlas/Role=production/Capability=NULL\r\nattribute : /atlas/Role=NULL/Capability=NULL\r\nattribute : /atlas/lcg1/Role=NULL/Capability=NULL\r\nattribute : /atlas/usatlas/Role=NULL/Capability=NULL\r\nattribute : nickname = yangw (atlas)\r\n\r\n\r\n\r\nI _think_ when we initiate the proxy, we can control which one is first in the list of attributes. So we can either take all attributes (if we figure out how), or the first one (or last one), similar to what VOMSXRD does.\r\n\r\nI think something like \"grps: '/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL’” is the cleanest. People can tell immediately who gets what in authdb. Q: Can the NULL items be ignored? How do we handle those spaces in authdb?\r\n\r\nregards,\r\n--\r\nWei Yang  |  <a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>  |  650-926-3338(O)  \r\n\r\n\r\n\r\n\r\n\r\n\r\nFrom:  Fabrizio Furano \<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>\u003e\r\nReply-To:  xrootd/xrootd \<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>\u003e\r\nDate:  Thursday, August 31, 2017 at 8:37 AM\r\nTo:  xrootd/xrootd \<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>\u003e\r\nCc:  Subscribed \<a href="/cgi-bin/wa?LOGON=A3%3Dind1708%26L%3DXROOTD-DEV%26E%3Dquoted-printable%26P%3D793753%26B%3D----%253D%253D_mimepart_59a8410d92386_46d43febd061dc3410855c%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26pending%3D" target="_parent" >[log in to unmask]</a>\u003e\r\nSubject:  Re: [xrootd/xrootd] secxtractor attributes not used for authentication (#566)\r\n\r\n\r\nHi,\r\n\r\nFYI, we will push a new release of XrdHttpVOMS (0.2.5) to epel-testing in the next few days,\r\nhere's an example of the way it extracts groupnames from the primary fqan:\r\n\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - user: '/DC=ch/DC=cern/OU=Organic\r\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano'\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - vorg: 'dteam'\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - fqan[0]:/dteam/Role=NULL/Capability=NULL\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - grps: '/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL'\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS data - role: 'NULL'\r\n170831 17:27:12 4327 furano.0:24@lxplus023 VOMS proxy info - name: '/DC=ch/DC=cern/OU=Organic\r\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano' VO: dteam grps: '/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL'\r\n\r\nPlease let me know if you think that there's anything to fix for XrdAcc to treat correctly these fields.\r\n\r\nCheers\r\nFabrizio\r\n\r\nOn 08/21/2017 10:00 PM, xrootd-dev wrote:\r\n\u003e Thank you Brian for explaining slash usage.\r\n\u003e \r\n\u003e On Mon, 21 Aug 2017, Brian Bockelman wrote:\r\n\u003e \r\n\u003e\u003e Looking at what I did for `XrdLcmaps`:\r\n\u003e\u003e - *space*-separated list of groups.\r\n\u003e\u003e - They should start with a slash; VOMS groups are hierarchical (i.e., `/atlas/foo/bar` is distinct from `/atlas/baz`) unlike\r\n\u003e Unix groups.\r\n\u003e\u003e\r\n\u003e\u003e One open question is how we should handle a proxy certificate with multiple VOMS extensions present - i.e., a proxy\r\n\u003e certificate with both ATLAS and CMS extensions. After all, it's perfectly acceptable for the CMS VOMS server to sign an\r\n\u003e extensions with FQAN `/atlas`. It's traditional that CMS group names are prefixed with `/cms`, but not enforced or validated by\r\n\u003e the client.\r\n\u003e\u003e\r\n\u003e\u003e --\r\n\u003e\u003e You are receiving this because you commented.\r\n\u003e\u003e Reply to this email directly or view it on GitHub:\r\n\u003e\u003e https://github.com/xrootd/xrootd/issues/566#issuecomment-323732506\r\n\u003e\u003e\r\n\u003e\u003e ########################################################################\r\n\u003e\u003e Use REPLY-ALL to reply to list\r\n\u003e\u003e\r\n\u003e\u003e To unsubscribe from the XROOTD-DEV list, click the following link:\r\n\u003e\u003e https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV\u0026A=1\r\n\u003e \r\n\u003e —\r\n\u003e You are receiving this because you were mentioned.\r\n\u003e Reply to this email directly, view it on GitHub \u003chttps://github.com/xrootd/xrootd/issues/566#issuecomment-323838017\u003e, or mute\r\n\u003e the thread \u003chttps://github.com/notifications/unsubscribe-auth/AFIaTwo5eEUSSlPBrtJwbPCOFLIQ-Ihxks5saeHsgaJpZM4O7mEG\u003e.\r\n\u003e \r\n—\r\nYou are receiving this because you are subscribed to this thread.\r\nReply to this email directly, \r\nview it on GitHub \u003chttps://github.com/xrootd/xrootd/issues/566#issuecomment-326334551\u003e, or \r\nmute the thread \u003chttps://github.com/notifications/unsubscribe-auth/AE9TAxeOEcdB1AKP4IwI3l_TOqKEX6PYks5sdtNJgaJpZM4O7mEG\u003e.\r\n\r\n\r\n{\"api_version\":\"1.0\",\"publisher\":{\"api_key\":\"05dde50f1d1a384dd78767c55493e4bb\",\"name\":\"GitHub\"},\"entity\":{\"external_key\":\"github/xrootd/xrootd\",\"title\":\"xrootd/xrootd\",\"subtitle\":\"GitHub repository\",\"main_image_url\":\"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png\",\"avatar_image_url\":\"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png\",\"action\":{\"name\":\"Open in GitHub\",\"url\":\"https://github.com/xrootd/xrootd\"}},\"updates\":{\"snippets\":[{\"icon\":\"PERSON\",\"message\":\"@ffurano in #566: Hi,\\n\\n FYI, we will push a new release of XrdHttpVOMS (0.2.5) to epel-testing in the next few days,\\nhere's an example of the way it extracts groupnames from the primary fqan:\\n\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - user: '/DC=ch/DC=cern/OU=Organic\\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano'\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - vorg: 'dteam'\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - fqan[0]:/dteam/Role=NULL/Capability=NULL\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - grps: '/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL'\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS data - role: 'NULL'\\n170831 17:27:12 4327 furano.0:24@lxplus023  VOMS proxy info - name: '/DC=ch/DC=cern/OU=Organic\\nUnits/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano' VO: dteam grps: '/dteam /dteam/Role=NULL /dteam/Role=NULL/Capability=NULL'\\n\\n Please let me know if you think that there's anything to fix for XrdAcc to treat correctly these fields.\\n\\nCheers\\nFabrizio\\n\\nOn 08/21/2017 10:00 PM, xrootd-dev wrote:\\n\\u003e Thank you Brian for explaining slash usage.\\n\\u003e \\n\\u003e On Mon, 21 Aug 2017, Brian Bockelman wrote:\\n\\u003e \\n\\u003e\\u003e Looking at what I did for `XrdLcmaps`:\\n\\u003e\\u003e - *space*-separated list of groups.\\n\\u003e\\u003e - They should start with a slash; VOMS groups are hierarchical (i.e., `/atlas/foo/bar` is distinct from `/atlas/baz`) unlike\\n\\u003e Unix groups.\\n\\u003e\\u003e\\n\\u003e\\u003e One open question is how we should handle a proxy certificate with multiple VOMS extensions present - i.e., a proxy\\n\\u003e certificate with both ATLAS and CMS extensions. After all, it's perfectly acceptable for the CMS VOMS server to sign an\\n\\u003e extensions with FQAN `/atlas`. It's traditional that CMS group names are prefixed with `/cms`, but not enforced or validated by\\n\\u003e the client.\\n\\u003e\\u003e\\n\\u003e\\u003e --\\n\\u003e\\u003e You are receiving this because you commented.\\n\\u003e\\u003e Reply to this email directly or view it on GitHub:\\n\\u003e\\u003e https://github.com/xrootd/xrootd/issues/566#issuecomment-323732506\\n\\u003e\\u003e\\n\\u003e\\u003e ########################################################################\\n\\u003e\\u003e Use REPLY-ALL to reply to list\\n\\u003e\\u003e\\n\\u003e\\u003e To unsubscribe from the XROOTD-DEV list, click the following link:\\n\\u003e\\u003e https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV\\u0026A=1\\n\\u003e \\n\\u003e —\\n\\u003e You are receiving this because you were mentioned.\\n\\u003e Reply to this email directly, view it on GitHub \\u003chttps://github.com/xrootd/xrootd/issues/566#issuecomment-323838017\\u003e, or mute\\n\\u003e the thread \\u003chttps://github.com/notifications/unsubscribe-auth/AFIaTwo5eEUSSlPBrtJwbPCOFLIQ-Ihxks5saeHsgaJpZM4O7mEG\\u003e.\\n\\u003e \\n\"}],\"action\":{\"name\":\"View Issue\",\"url\":\"https://github.com/xrootd/xrootd/issues/566#issuecomment-326334551\"}}}\r\n"}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/566#issuecomment-326359438"}}}</script><br>
<hr>
<p align="left">
Use REPLY-ALL to reply to list</p>
<p align="center">To unsubscribe from the XROOTD-DEV list, click the following link:<br>
<a href="https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1" target="_blank">https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1</a>
</p>