Print

---

@abh3 Many thanks for this nice summary!

b) The dn hash is a specific feature of gsi authentication. Given that http does not use gsi, it never develops a hash. It's not clear whether we should change that or not. I suppose we could make it an option. Thoughts?

I think that if the DN can be used, consistent use of the hash is not as important anymore. My main reason to even consider using the hash was that using the DN failed due to the spacechar issue.

Concerning the DN usage, I agree you are right: For any elaborate, experiment-specific mapping, an external algorithm is used and this will likely stay this way, especially for the large experiments. The use cases I am thinking of are related to smaller user bases, so some examples could be:

• Granting special privileges to single users (e.g. site admins, robots, debugging). I'm thinking of use cases for which the list is short (<10 people or robots) and manageable, e.g. small local user communities, site admins or even a DAQ robot uploading data.
• Accepting only users from a specific OU of the OUs CA.
• Blocking single users / DNs (e.g. "account hacked") before the official CRL is updated.

The initial use case I had in mind when creating this issue was indeed just "granting users ingesting data write privileges", allowing regular users (granted permissions by VOMS extensions) to only read the data. But we also have other of the use cases listed above for which this might be helpful, and I think these are mostly generic so I believe they could be helpful to many users.

Now for the implementation. Of course, you are right when you write:

Now as for using the dn. It's problematic because as far as I can tell the order of the elements in the dn field is not standardized. Additionally, some of these are optional. So, doing a simple comparison is not sufficient. You have to parse the DN and compare element by element. That's something we don't do which makes the dn field not particularly useful.

However, since the external algorithms exist for the more complex use cases, and likely won't ever be fully replaced by anything thought up here, I wonder if the following approach would work: Match the string in the auth file against the DN, but allow for wildcards / a regular expression. Since the CAs are trusted to not violate each others namespaces / DNs, and the DNs are hierarchical, this might be sufficient. To give some examples, it would allow to:

• Match against something like ^/C=DE/O=GermanGrid/OU=UniBonn/.* (or any other OU) without actually parsing the DN.
• Explicitly match against a single DN (to exclude it or grant it special privileges).
• Depending on the CAs which are trusted (e.g. a small user group may even have their own CA), matching by a single component of the DN might even be a reasonable use case.

In the end, a regexp / wildcard solution would delegate the definition of what is acceptable to the user, who has to specify which components of the DN must match a specific pattern. I presume it might also be the "easiest" implementation, and would be sufficient for the use cases I can think of.

Of course, you are right that string matching is not fully correct, and parsing the DN into components and treating these would be much more versatile — but also much more complex. This article has a nice summary on why the elements of DNs "commonly" are in hierarchical order (due to inspiration of X.509 by directory services). That's also the case for all DNs I have encountered so far, and what the commonly trusted CAs (CAs issuing web certificates or CAs in use in WLCG) ensure. However, it is not in any standard, so there is no guarantee for that to be the case for "everything X.509".

Having a regexp / wildcard solution would delegate the wanted "strictness" and the definition of what is "acceptable" to the user writing the auth file. Since the user also defines which CAs to trust by defining the trust store, this might be a reasonable assumption to make. What do you think?

Now finally, to the last point:

a) The reason that spacechar was not applied is that we don't apply it for "=" (anyuser) or '*" (alluser). I can't recall the reasoning behind that restriction. So, please think about it and how those two rules are used and let me know your thoughts on whether we should lift the restriction. However, before you do that, consider point (b).

I also can not think of a reasoning behind that restriction. I'll ponder about it a bit more, but I currently can't imagine a situation in which it would "hurt" to lift the restriction,

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

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