How to fetch a WLCG token with scope storage.read:/sometestdir from IAM?

WLCG Token Authorization
1

Hi together,

to make Discourse a bit more alive and not bother the mailing list, I start with a question — trying to test the configuration of our XRootD instance in Bonn, I want to fetch a token with a storage.read:/somewhere scope, to then test access. But it seems I can’t get an access token with this scope from the IAM.

Here’s what I have:

$ oidc-gen -p wlcg | jq .scope
"openid profile compute.create storage.read:/ compute.read compute.modify wlcg eduperson_entitlement storage.create:/ offline_access compute.cancel eduperson_scoped_affiliation storage.modify:/ email wlcg.groups"

i.e. I have storage.read:/ in the scopes of my refresh token.

However, I can’t get that into an access token:

$ for T in $(oidc-token --aud https://xrootd.physik.uni-bonn.de:1094 -s wlcg.groups -s storage.read:/ wlcg | tr '.' '\n' | head -2); do echo $T | base64 -d | jq; done
...
{
  "wlcg.ver": "1.0",
  "sub": "<some-uuid>",
  "aud": "https://xrootd.physik.uni-bonn.de:1094",
  "nbf": 1647003829,
  "scope": "wlcg.groups",
  "iss": "https://wlcg.cloud.cnaf.infn.it/",
  "exp": 1647007429,
  "iat": 1647003829,
  "jti": "<some-uuid>",
  "client_id": "<some-uuid>",
  "wlcg.groups": [
    "/wlcg"
  ]
}

As you can see, the scopes claim for storage.read:/ is missing. For reference, specifying something else such as -s wlcg.groups works fine, as shown above.
What am I doing wrong? Am I missing a step in IAM registration?

Cheers and thanks,
Oliver

2

Hi Oliver,

I can’t explain why you’re having the problem. It works for me. I get:

{
  "wlcg.ver": "1.0",
  "sub": "af58f768-0e6a-4911-b7ab-a46a65d1c132",
  "aud": "https://xrootd.physik.uni-bonn.de:1094",
  "nbf": 1647035016,
  "scope": "storage.read:/ wlcg.groups",
  "iss": "https://wlcg.cloud.cnaf.infn.it/",
  "exp": 1647038616,
  "iat": 1647035016,
  "jti": "e23db87f-3aeb-4f0a-bba9-054498723f2d",
  "client_id": "db9c929f-7476-4b0e-8218-15bfa26bd2f1",
  "wlcg.groups": [
    "/wlcg",
    "/wlcg/pilots",
    "/wlcg/xfers"
  ]
}

I can even add additional components to the scope, for example storage.create:/subdir and the token comes back with that.

I do have “token exchange” enabled on my client, but I don’t think oidc-agent uses that. I had to ask the administrator to enable that feature so I could use it from vault.

Dave

3

Dear Dave,

thanks, then at least it seems I’m not something blatantly wrong in terms of commands. I did now also exclude the more obscure possibilities by trying it out not only with my own build of oidc-agent, but also with the packages from http://repo.data.kit.edu/ on CentOS 7 and CentOS 8 Stream, and results are consistent.

I currently only have the wlcg group in the IAM. Is it possible the storage.read:/ claims are only granted when also requesting wlcg.xfers, or another group?
I have now requested access to wlcg/test (as seems to be used by the JWT Compliance Tests), wlcg/xfers and wlcg/pilots. I would not expect the groups to have an effect on storage.xyz:/ claims, but this is the only idea I could come up with by now.

Cheers,
Oliver

4

Dear Dave,

that did the trick! So it seems the storage.xyz:/ claims are coupled to IAM group memberships. Since I registered with wlcg.test, wlcg.pilots and wlcg.xfers in one go, I don’t know which group did the trick (I’d guess it was wlcg.xfers), but now it works for me like a charm, i.e. I can request storage.read:/ or also storage.read:/somedir and get the scopes into my token.

Interestingly, wlcg.test does not show up in the wlcg.groups array by default. But it seems I can request it with -s wlcg.groups:/wlcg/test now, so that’s probably to be expected (and simplifies tests actually). So now I can continue to find out why our XRootD does not yet grant permissions as expected when storage.xyz:/ claims are present in the token, to get the JWT compliance tests all green.

Thanks and cheers,
Oliver

5

For those who want to follow along, I now have all JWT Compliance tests against an XRootD redirector setup “green” apart from storage.xyz:/ path authorization tests. Now that I can get an appropriate claim into my tokens, I’ve pinned down the issue:

With this, I’ll mark this thread as resolved and things can continue in the linked issue :-).