Can't get macaroon using token?

[DmitryLitvintsev]

I can get macaroon using x509 authentication:

SRC="https://amsc.fnal.gov:2880/amsc/test"

curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:DOWNLOAD"], "validity": "PT1M"}' "$SRC" | jq -r '.macaroon'
MDAyMmxvY2F0aW9uIE9wdGlvbmFsWy9hbXNjL3Rlc3RdCjAwMThpZGVudGlmaWVyIE96UGdVTFpECjAwMTVjaWQgaWlkOnhndHJnbmZQCjAwMmNjaWQgaWQ6OTgxMTsxOTk5LDUwNjMsOTExNCw5MjQ3O2Ntc3Byb2QKMDAyZWNpZCBiZWZvcmU6MjAyNi0wMi0yN1QxNzowNzoyMC43MzM3NTQ3MDNaCjAwMThjaWQgcGF0aDovYW1zYy90ZXN0CjAwMWFjaWQgYWN0aXZpdHk6RE9XTkxPQUQKMDAyZnNpZ25hdHVyZSAS2KHxffllc61OT-h3JnLVUwcRcMNE8X5jZRXAUhNmcgo

If I try to use token I fail:

{
  "sub": "408c3486-b1ce-4d3d-ab3f-74717f80a534",
  "iss": "https://cilogon.org/fermilab",
  "wlcg.ver": "1.0",
  "aud": "https://wlcg.cern.ch/jwt/v1/any",
  "acr": "https://refeds.org/profile/sfa",
  "nbf": 1772212166,
  "auth_time": 1772212169,
  "scope": "storage.create:/amsc/neutrino/dune compute.cancel compute.create storage.modify:/amsc/neutrino/dune compute.read storage.read:/amsc/neutrino/dune compute.modify",
  "exp": 1772222971,
  "iat": 1772212171,
  "wlcg.groups": [
    "/amsc/dunewrite",
    "/amsc"
  ],
  "jti": "https://cilogon.org/oauth2/6761206a8eda2fcd5e5112615786406b?type=accessToken&ts=1772212171136&version=v2.0&lifetime=10800000"
}

export BEARER_TOKEN=$(< $XDG_RUNTIME_DIR/bt_u$(id -u))
export SRC="https://amsc.fnal.gov:2880/amsc/neutrino/dune"

curl -v -X POST -H "Authorization: Bearer ${BEARER_TOKEN}" -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:DOWNLOAD"], "validity": "PT1M"}' "$SRC" export BEARER_TOKEN=$(< $XDG_RUNTIME_DIR/bt_u$(id -u))
...

> 
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Cannot serialise restriction MultiTargetedRestriction
< Date: Fri, 27 Feb 2026 17:26:53 GMT
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: 
< Access-Control-Allow-Origin: https://amsc.fnal.gov:2880
< Strict-Transport-Security: max-age=31536000
< Feature-Policy: accelerometer 'none' ; ambient-light-sensor 'none' ; camera 'none' ; encrypted-media 'none' ; fullscreen 'none' ; geolocation 'none' ; gyroscope 'none' ; magnetometer 'none' ; microphone 'none' ; midi 'none' ; payment 'none' ; speaker 'none' ; sync-xhr 'self' ; usb 'none' ; vr 'none' ; picture-in-picture 'none'
< Referrer-Policy: strict-origin-when-cross-origin
< Content-Length: 0
< 
* Connection #0 to host amsc.fnal.gov left intact

The salient error:

HTTP/1.1 400 Cannot serialise restriction MultiTargetedRestriction

Am I doing something wrong or this is broken?

The error is printed from :

https://github.com/dCache/dcache/blob/master/modules/dcache-webdav/src/main/java/org/dcache/webdav/macaroons/MacaroonRequestHandler.java#L270

where it just loops over LoginAttributes and returns ErrorResponseException in case LoginAttribute is of type Restriction

[paulmillar]

Of your two options, it's more the "this is broken" choice, but perhaps better described as a "known" limitation of the current approach.

You should be able to create a macaroon from an access token, if it doesn't have AuthZ statements in the scope claim. The problem is your access token has AuthZ statements in the scope claim.

Your specific example has three scope claims, but they target the same path:

storage.create:/amsc/neutrino/dune 
storage.modify:/amsc/neutrino/dune 
storage.read:/amsc/neutrino/dune 

The code in ScopeBasedAuthzProfile#buildRestriction actually merges the authorisation with a common path, so there's a single authorisation for that path. However, in the general case there may be different authorisations at different paths.

The MultiTargetedRestriction is the Restriction that honours the authorisation of the scope claim.

From memory, I believe the macaroon caveat AuthZ language (i.e., the things written into the macaroon) could support a scope claim with AuthZ statements that alll target the same path. However, the caveat authorisation language can't describe the general scope claims.

When requesting a macaroon, the code tries to serialise the user's limitations as caveats. For MultiTargetedRestriction.
it gives up because (in the general case) it can't write a macaroon that would honour the restriction.

How to fix this?

There's a few options:

1. ScopeBasedAuthzProfile#buildRestriction could check whether the scope AuthZ statements all target the single directory. When it sees this, it could use a different set of restrictions, ones that the macaroon code knows how to serialise as caveats. This is not a general solution, but it would work for this case.

2. The macaroon serialiser could add limited support for MultiTargetedRestriction: if there is a single directory then write the corresponding macaroon, otherwise fail. Also not a general solution, but would work for this case.

3. Extend the macaroon caveat AuthZ language to support something equivalent to the scope claim and update the macaroon serialiser/deserialiser code to convert between MultiTargetedRestriction and this scope-claim-equivalent caveat.

4. Stop trying to create a macaroon, just use the access token instead.

Of these, option 4. is likely the easiest to implement.

[DmitryLitvintsev]

4. Stop trying to create a macaroon, just use the access token instead.

Of these, option 4. is likely the easiest to implement.

Hi Paul,

Yes, I have tried that but failed. Is this supposed to work:

I am trying to copy file from one dCache instance to another:

htgettoken -a htvaultprod.fnal.gov -i dune
export TSRC=$(< $XDG_RUNTIME_DIR/bt_u$(id -u))
htgettoken -a htvaultprod.fnal.gov -i amsc -r dunewrite
export TDST=$(< $XDG_RUNTIME_DIR/bt_u$(id -u))

curl -v --capath /etc/grid-security/certificates -L -X COPY -H 'Secure-Redirection: 1' -H 'X-No-Delegate: 1' -H 'Credentials: none' -H "Authorization: Bearer $TDST" -H "TransferHeaderAuthorization: Bearer $TSRC" -H "TransferHeaderTest: Test"  -H "Source: https://fndcadoor.fnal.gov:2880/dune/scratch/users/litvinse/1GB.data" https://amsc.fnal.gov:2880/amsc/neutrino/dune/litvinse/1GB.data

I get:

< HTTP/1.1 500 Error performing OpenId-Connect delegation

In the log file:

Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] cilogon.org:443 requested authentication
Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] Response contains no authentication challenges
Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] Invalid cookie header: "Set-Cookie: AWSALB=QcyZ1qw6MaXy5F0ktMxouRoNre3jIp/IaFLhkdNivt3XExje2Qqc4VBm1JDwCxfwiGZL1owaHE1P23dz+GaPy+P8GfSikZeI7wLRAXAyon1iqB+qq1gn1vz/irVm; Expires=Wed, 11 Mar 2026 06:08:45 GMT; Path=/". Invalid 'expires' attribute: Wed, 11 Mar 2026 06:08:45 GMT
Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] Invalid cookie header: "Set-Cookie: AWSALBCORS=QcyZ1qw6MaXy5F0ktMxouRoNre3jIp/IaFLhkdNivt3XExje2Qqc4VBm1JDwCxfwiGZL1owaHE1P23dz+GaPy+P8GfSikZeI7wLRAXAyon1iqB+qq1gn1vz/irVm; Expires=Wed, 11 Mar 2026 06:08:45 GMT; Path=/; SameSite=None; Secure". Invalid 'expires' attribute: Wed, 11 Mar 2026 06:08:45 GMT
Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] OIDC delegation failed: [cilogon.org -> java.io.IOException: Http Request Error (401): []]
Mar  4 00:08:45 amsc00 dcache@webdav-amsc00Domain[51575]: 04 Mar 2026 00:08:45 (WebDAV00-amsc00) [door:WebDAV00-amsc00@webdav-amsc00Domain:AAZMLKcYDDg] COPY :: amsc.fnal.gov:2880///amsc/neutrino/dune/litvinse/1GB.data finished 68ms, Status:null, Length:null

The settings I have:

webdav.oidc.client.id!cilogon.org = host:dcache.fnal.gov
webdav.oidc.client.secret!cilogon.org = CENSORED

I can get access token by issuing:

curl -s --request POST --url https://cilogon.org/oauth2/token   --header 'content-type: application/x-www-form-urlencoded'   --data "client_id=host:dcache.fnal.gov&client_secret=CENSORED&grant_type=client_credentials" | jq -r .access_token

Vanilla dCache gets 404, because it posts to https://cilogon.org/token. I hacked it to post to https://cilogon.org/oauth2/token and now get 401 that I quoted above.

Am I doing something wrong or am I sailing the uncharted waters here and there is just bug there? It this supposed to work? I thought Anupan demonstrated OIDC HTTP TPC back in 2016 or so.

[paulmillar]

I recommend reading through the HTTP-TPC documentation.

Short answer: you have a typo in your header: Credentials: none should be Credential: none

[DmitryLitvintsev]

Short answer: you have a typo in your header: Credentials: none should be Credential: none

yup! that was it.

[paulmillar]

Excellent. Good to hear!

Just to mention a few things:

• dCache currently ignores the X-No-Delegate header. We could also implement it (instead of supporting Credential)
• The default value for Credential header (if not specified) should probably be none in all cases. It's a historical accident that it isn't and it's just causing problems.
• We might even consider ripping out delegation support altogether, if GridSite (for X.509 delegation) isn't needed any more.

[DmitryLitvintsev]

So delegaiton is not needed for OIDC? I was following

https://www.dcache.org/manuals/Book-10.1/config-gplazma.shtml#using-openid-connect

(section "Third-Party Transfer with OpenID Connect Credentials”)

“””

Third-party transfer with OpenID Connect Credentials are also possible. dCache performs a token-exchange with the OpenID provider in order and obtain a new delegated bearer token for itself, which it can use (and refresh) to perform Third-party transfer.

In order to perform a token-exchange, it requires the id and secret of a client registered to the OpenID Provider same as that of the bearer token (that was received with the COPY request).

The client-id and client-secret of such a client can be set in the webdav properties as follows,

webdav.oidc.client.ids!provider.hostname : id of a client registered to an OpenId Provider

webdav.oidc.client.secrets!provider.hostname : client-secret corresponding the client-id specified above
Here, provider.hostname must be replaced with a supported OpenID provider like accounts.google.com.

“”"

[paulmillar]

No, you don't need to use OAuth2 token exchange to have a successful HTTP-TPC transfer using OIDC access tokens.

The token-exchange brings certain benefits:

1. dCache can change the audience claim in the token to the destination service.
2. dCache fetches a refresh token when the transfer is requested, which is (or can be?) used to fetch an up-to-date access token when the transfer actually starts.

That said, 1. is difficult to achieve (how do you know the correct audience?) and mostly unnecessary due to WLCG's security model for audience claims. 2. likely brings only marginal benefits.

Without token exchange, the client provides dCache with the two OIDC access tokens: one to authorise the access within dCache (Authorization header), and the other authorise access on the passive endpoint (TransferHeaderAuthorization header).

WLCG/FTS/Rucio uses this second approach, supplying dCache two access tokens. No token-exchange takes place.

The Credential: none header switches off the OAuth2 token exchange support.

[DmitryLitvintsev]

Should we reflect this in documentation (I took the text as requirement and started requestng client_id/secret). And may be even removing it from code base altogether?

[paulmillar]

I agree the documentation text does give the impression that token-exchange is necessary for OIDC-based HTTP-TPC, which isn't true.

It would make sense to update the documentation to describe the two options:
- dCache generates the token for the data-bearing transfer, using the OAuth2 token exchange endpoint and the token from COPY request.
- the client supplies both tokens: one for the COPY request and the other for the data-bearing transfer.

For removing the delegation features (GridSite and OIDC): yes, delete it if it's not needed.

Here's how I would go about it.

First, add a configuration property that disables delegation support. The default for this configuration property would be to disable delegation. If a dCache admin discovers this is causing problems, then can update the configuration property value to re-enable delegation support.

Assuming nobody reported re-enabling delegation then (for example) one golden release later, support for X.509 (GridSite) and OIDC delegation can be simply removed.