New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path authorization tests fail if SE does not use path /
#34
Comments
Hi, also in StoRM WebDAV we have an endpoint (
and when we specify that we want to read recursively just in a subpath of that endpoint (
So, is it possible to configure the XrootD authz in the same way as StoRM WebDAV does? |
Just to add more informations if it can be of any help in the debug: the compliance testsuit logic is based on checking permissions on subpaths that do not exist and expects to receive a For instance
this would result in a green test.
This looks strange to me.
while I have the same behavior as above if I use the full path in the token
|
I can confirm, and also reproduce with
I had a deeper look, this does indeed seem to be possible at the token plugin configuration level. Here, I can set a "base path" which is then assumed to be part of the directory in the storage claim. I will reconfigure all nodes this way now, so we should see the effect in the tests tomorrow. A problem / feature with this configuration is that this is done "by issuer", i.e. it disallows granting access to tokens issued by the WLCG issuer to any paths outside the given base path. In a larger picture, this may make things harder where one issuer serves several organizations, which then can't have their base path since the base path is couple to the issuer. A notable example from our current configuration is that the path:
contains the SRR JSON, accessible by all WLCG VOs. After adapting the base path for the WLCG VO, it is not accessible via WLCG tokens with storage claims anymore, since it is outside of the "wlcg" path. Or rephrased: Things can't be shared between different issuers. Let's see if this fixes the tests (my change will become active in ~30 minutes in case you want to test manually before that ;-) ). |
I believe this is caused by: |
"Path authorization" tests are green now (see here); it worked, thank you! |
Thanks for re-running the tests, this looks great indeed — with only one failing test remaining, it's the greenest XRootD in the tests for sure (and being a redirector-setup with multiple DTNs and shared FS, already a complex one) 👍.
Indeed. I believe that is (currently) by design, basically in the same place I linked before, the auth mapping is done: Since the underlying library exposes the more detailed information already, this should be easy to change. I'll give this a go along with the |
All (known) issues are now fixed with XRootD 5.5.0, which we have upgraded to last night :-). This means:
The JWT compliance test run from today shows 100 % "green" for |
Trying to get all tests with the XRootD redirector setup at UBonn "green", I found the only remaining issue is about path authorization tests.
The existing tests right now use a claim such as:
to test. However, an endpoint may have a path already, such as:
So a matching claim would be:
Trying with such a claim against the endpoint works as expected.
The text was updated successfully, but these errors were encountered: