Uploaded image for project: 'FTS'
  1. FTS
  2. FTS-1835

Configurable token-exchange audience field



    • New Feature
    • Status: Closed
    • Medium
    • Resolution: Fixed
    • fts-rest-server 3.12.0
    • fts-rest-server 3.12.1
    • FTS-Flask
    • Security Level: Public Data (This ticket is visible to anyone on the internet and will be indexed by search engines)
    • None


      With the transition from certificates to tokens, FTS ends up interacting with different token provider implementations.

      The issue at hand shows up during the token exchange workflow and presents contradicting requirements between Helmholtz TokenProvider (based on Unity IDM) and WLCG (based on IAM):

      1. Unity requires the audience to always be the client_id of the token-exchange requester. This would mean audience=<fts_client_id> in all cases. [1]
      2. Within the WLCG profile, the audience is optional, acts as a filter and targets a storage resource (or the general "https://wlcg.cern.ch/jwt/v1/any"). If the audience is the fts_client_id, then each storage would need to know about the FTS client, which is not wanted.
      3. Ultimately, the token-exchange specification mentions the audience as an optional field and the entity for which the token is intended. [2]


      Given the conflicting requests, the best FTS can do for the moment is make the audience claim also configurable per token provider.

      The new behavior will look like this:

      • If the claim is configured, then FTS will always use that during the token exchange
      • if the token is identified as WLCG token, the "https://wlcg.cern.ch/jwt/v1/any" audience is used
      • Otherwise, no audience claim is set

      [1] https://www.unity-idm.eu/documentation/unity-3.9.0/manual.html#_token_exchange
      [2] https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3




            mipatras Mihai Patrascoiu
            mipatras Mihai Patrascoiu
            0 Vote for this issue
            3 Start watching this issue