OIDC: better logging needed when access denied

[onnozweers]

Dear dCache devs,

I got a token from an IAM that made dCache refuse my upload with a 403.

{
    "wlcg.ver": "1.0",
    "sub": "15666f36-40a0-4ef0-af8b-08d962deb769",
    "aud": "https://wlcg.cern.ch/jwt/v1/any",
    "nbf": "2024-05-17 15:17:45 CEST+0200",
    "scope": "openid offline_access profile storage.stage:/ wlcg.groups",
    "iss": "https://iam-escape.cloud.cnaf.infn.it/",
    "exp": "2024-05-17 16:17:45 CEST+0200",
    "iat": "2024-05-17 15:17:45 CEST+0200",
    "jti": "1faa5953-2ae2-4241-a8f2-514f523d6b8c",
    "client_id": "40e39042-2d9e-4c33-b8a6-66142d2a2a7b",
    "wlcg.groups": [
        "/escape",
        "/escape/ska"
    ]
}

Downloading a file however, succeeded.

With the following token however, I was permitted to upload a file:

{
    "wlcg.ver": "1.0",
    "sub": "15666f36-40a0-4ef0-af8b-08d962deb769",
    "aud": "https://wlcg.cern.ch/jwt/v1/any",
    "nbf": "2024-05-17 12:04:51 CEST+0200",
    "scope": "openid wlcg.groups profile offline_access",
    "iss": "https://iam-escape.cloud.cnaf.infn.it/",
    "exp": "2024-05-17 13:04:51 CEST+0200",
    "iat": "2024-05-17 12:04:51 CEST+0200",
    "jti": "863d073f-4a44-404a-8f32-54c402a07681",
    "client_id": "136da3f0-04ce-43bc-a043-2ba79f098af2",
    "wlcg.groups": [
        "/escape",
        "/escape/ska"
    ]
}

My guess is that the storage.stage:/ in the scope made the difference. I guess that dCache, when any storage.* property is in the token, decides that you also need a storage.create: property to upload anything. Is that correct? Is this documented somewhere?

[As a sidenote: my oidc client scope included storage.read:/ storage.stage:/ storage.create:/ storage.modify:/, but the returned token included storage.stage:/ and not storage.read:/ storage.create:/ storage.modify:/ so I guess the IAM might be strangely configured.]

My next question: I've set logging to DEBUG level in both the WebDAV door and the gPlazma cell in our test environment. gPlazma did not log anything when my upload was denied. The WebDAV door logged 1500 lines just for my upload, but I was unable to find any clue why my upload was denied. In the billing files I couldn't find any clue either. In the access file there was a response.code=403, but not even a response.reason. Could logging please be improved?

[DmitryLitvintsev]

Hi Onno,

@paulmillar may correct me, but this looks similar to what was observed before - ability to read from directories if storage scope is not present. Which, I believe was done for some kind of backward compatibility. "it" falls back to storage-authzdb (or similar) plugin to determine accessible path. Presense of adny storage* scope is treated as a hint that "aha, we now using scopes" and if they are not present this is treated as you have not access at all. I think I am getting this right. Paul may correct me if I am wrong.

IMO this is confusing. I woiuld prefer that your second token allowed you to do nothing at all on the system.

[kofemann]

@onnozweers indeed, any storage.* scope turns the token into a authorization token. So, as there is no storage.create, the writing is forbidden.
Obviously, the logging must report that.

[paulmillar]

Is that correct?

Yes.

If there are any explicit AuthZ statements in the token then the bearer (the client with the token) is authorised to make those operations (dCache will ignore the permissions in the namespace). If the token has no explicit AuthZ statements then dCache will enforce the permissions in the namespace.

Is this documented somewhere?

Surprisingly, also yes (or, at least, a "mostly"):

In addition, the scope claim is examined to see if it contains explicit authorisation statements. If the token contains any such explicit authorisation statements then the token is considered an authorisation token; if the token contains no such authorisation statements then it is considered a non-authorisation token.

The description is missing some details, though: what is an explicit authorisation statement and what is the consequences of the token being considered an authorisation token (or a non-authorisation token).

[onnozweers]

Just an additional question. How long are non-authorization tokens going to be supported? At the moment it seems easy to circumvent storage.* limitations, by defining an OIDC client that simply does not have any storage.* properties in its scope, so that you get a non-authorization token. Is this indeed the case, or have I overlooked something?

[paulmillar]

That's a good question.

I think it would make sense to offer dCache admins the option (in dCache's configuration) on how to handle tokens from different OPs. This would allow an admin to configure whether or not to honour the explicit AuthZ (bypassing the namespace), and whether to fall back to group-based AuthZ (using the namespace) if a token has no explicit AuthZ statements.

The current dCache behaviour could be the default, but the admin could configure that dCache should completely ignore any explicit AuthZ statements, or that dCache should always using explicit AuthZ (no AuthZ implies the token can't do anything).

Like this, a site could try being stricter (dropping support for non-AuthZ tokens), but can revert back to the current behaviour if there's a problem.