[Story] Scoped Access Tokens through Authorization Services / UMA

Story

Persona: user of Cipherduck
Need: scoped token
Purpose: not be restricted in the number of vaults and configured storage backends

Acceptance Criteria

[ ] ~implement patch https://github.com/keycloak/keycloak/issues/22096~
[ ] ~move from user attributes (#10) to authorization resources in Keycloak~
[ ] ~distribution of client secret?~
[ ] ~client secret in client~
[x] implement ~UMA~ token-exchange call client-side: use access token instead of id token
[x] opt. implement ~UMA~ token-exchange call hub-side for bucket creation as well (see https://github.com/cryptomator/hub/issues/206)
[ ] ~containerize minio test~ -> #12
[x] test keychain multiple vaults with token-exchange
[x] test session lifetimes, first implementation does token-exchange immediately
[x] staging+AWS with token-exchange -> requires instance with token-exchange feature
[x] config from hub
[x] finalize documentation: decision, ER diagram, how many token exchanges?
[x] check on backup strategy of resources data in Keycloak
[x] cleanup dev-realm.json: which claim is required in hub for user role etc.? As users get one role per shared vault, this should not grow in access token!
[x] cleanup dev-realm.json clients cryptomatorvaults and realm-management
[x] remove client roles from access token or implement token exchange before STS bucket creation in frontend.

Open Questions

~Closer look at UMA data model and API to create resources, permissions, authorization scopes, authorization policies... tentatively:~
- ~1 Authorization Resource per Vault (has an associated Authorization Scope)~
- ~1 Authorization Policy per Vault: which users?~
- ~1 Authorization Policy per vault~
- ~1 Authorization Scope per backend type~
- ~1 resource-based permission per vault: links resource and policy~

Context

~Some lock-in to Keycloak and status of UMA specification deemed acceptable~
continuation of #10 to solve token size problem (scoped tokens)
~open discussion whether Keycloak authorization/permission should be the main source of truth for vault access management in hub~

Implementation

Problem: we want to avoid sending a token to AssumeRoleWithWebIdentity that grows with the number of vaults/roles added to the user.

Two options:

(1) Separate client cryptomatorvaults
- 🟢 we need to add scopes to only one client, not to cryptomator and cryptomatorhub
- 🟢 we can strip down the exchanged token to the bare minimum without affecting the existing scopes (in particular, the roles in cryptomator and cryptomatorhub are evaluated in hub REST services for access control (TODO double check this))
- 🔴 requires the admin-fine-grained-authz feature in Keycloak activated as well, as well as a policy allowing cross-client token-exchange to cryptomatorvaults, see ^1 ^3
- 🔴 requires token-exchange in all cases
- requires to specify target clientId in token-exchange via audience parameter in addition.
(2) Add vaults to existing clients cryptomator and cryptomatorhub
- 🟢 avoid complexity of addition admin-fine-grained-authz feature and corresponding configuration
- 🔴 we need to mis-use client roles to separate between roles added to token by default and strip down existing client configurations (cryptomator and cryptomatorhub)

Preliminary decision: try out (1) to see how it looks like eventually.

Test for (2):

function jwtd() {
    if [[ -x $(command -v jq) ]]; then
         jq -R 'split(".") | .[0],.[1] | @base64d | fromjson' <<< "${1}"
         echo "Signature: $(echo "${1}" | awk -F'.' '{print $3}')"
    fi
}
TOKEN=`curl -v -X POST http://localhost:8180/realms/cryptomator/protocol/openid-connect/token \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "client_id=cryptomator" \
     -d "scope=openid" \
     -d "grant_type=password" \
     -d "username=admin" \
     -d "password=admin"    | jq ".access_token" | tr -d '"'`
jwtd $TOKEN     
SCOPED_TOKEN=`curl -X POST http://localhost:8180/realms/cryptomator/protocol/openid-connect/token\
    -d "client_id=cryptomator" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "subject_token=$TOKEN" \
    -d "subject_issuer=http://localhost:8180/realms/cryptomator" \
    --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
    -d "audience=cryptomatorvaults" \
    -d "scope=openid c1089d35-0abe-4e51-ab58-ed8c1507efca" | jq ".access_token" | tr -d '"'`
jwtd $SCOPED_TOKEN

Problem: the token we create buckets with has all realm and client roles mapped into it by default. Two options:

(1) additional token-exchange before creating buckets using cryptomator or cryptomatorhub client
- 🔴 requires patching Keycloak.js or additional OIDC client, see https://github.com/keycloak/keycloak/discussions/17018. See also started snippet below.
- 🟢 standard default/optional client scopes in for cryptomator and cryptomatorhub clients.
(2) patch dev-realm.json:
- 🟢 Cryptomator hub so far does not use client roles. In Cipherduck, we use client roles in cryptomatorvaults only, so this seems a straightforward separation as long as there is no future usage of client roles for other purposes.
- 🔴 non-standard default/optional client scopes in for cryptomator and cryptomatorhub clients in dev-realm.json.
-> Let's go for (2) as long as there is no conflict with this approach.

Snippets for patching Keycloak.js (unfinished business):

 public async tokenExchange(): string{
    this.keycloak.tokenExchange = function(){
        var kc = this;

        var params = 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange"&' + 'subject_token=' + kc.accessToken;

        return new Promise(function (resolve, reject) {

            var url = kc.endpoints.token();
            var req = new XMLHttpRequest();
            req.open('POST', url, true);
            req.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
            req.withCredentials = true;

            params += '&client_id=' + encodeURIComponent(kc.clientId);

            var timeLocal = new Date().getTime();

            req.onreadystatechange = function () {
                if (req.readyState == 4) {
                    if (req.status == 200) {
                        console.log('[KEYCLOAK] Token refreshed');

                        timeLocal = (timeLocal + new Date().getTime()) / 2;

                        var tokenResponse = JSON.parse(req.responseText);

                        kc.onAuthRefreshSuccess && kc.onAuthRefreshSuccess();
                        resolve(tokenResponse['access_token'], tokenResponse['refresh_token'], tokenResponse['id_token'], timeLocal);
                    } else {
                        console.log('[KEYCLOAK] Failed to refresh token');

                        if (req.status == 400) {
                            kc.clearToken();
                        }

                        kc.onAuthRefreshError && kc.onAuthRefreshError();
                        reject();
                    }
                }
            };
            req.send(params);
        });
    };
    await this.keycloak.tokenExchange();
    return this.keycloak.token;
  }

N.B. Without roles.client.realm-management in dev-realm.json, we get: 2023-11-20 14:01:40 2023-11-20 13:01:40,731 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-1) Uncaught server error: java.lang.RuntimeException: Unable to find composite client role: realm-admin

shift7-ch / katta-server