JWT claim-based authorization vault/bucket/role setup MinIO+AWS aka. Role Chaining

[chenkins]

Story

• Persona: dev/ops/sec
• Need: only create roles at hub setup time AWS-side
• Purpose: prevent role escalation / complexity kills security

Acceptance Criteria

• finalize bucket naming convention --> implementation in Configurable prefix for bucket names, roles and policies #15
• where to store vaults in Keycloak: use user attribute or roles....? If user attribute vault instead of vaults
• cleanup dev-realm.json
  • re-use cryptomator client id to for cipherduck, see discussion Finalize vault storage configuration API #6, minimal diff to upstream
  • apply same setup in staging Keycloak
  • more transparency in keycloak configs for integration tests and local runs with password grant - can we do without duplicating the config?
  • what about user001 in dev-realm.json? Add it on the fly for integration tests?
  • syncer should not have full admin role in dev-realm.json
• Documentation aud etc.
• proper solution to allow AssumeRoleWithWebIdentity if no vault is shared with us. -> not required if we go for shift7-ch/katta-clientlib#30
  • MinIO setting
  • AWS setting
• Document design decision and considered alternatives
• Custom mapper AWS
• AWS/MinIO switch (which mapper -> already UMA?)
• frontend implementation create bucket AWS + MinIO using AssumeRoleWithWebIdentity Hub frontend/client UI vault storage configuration for STS #3
• implementation chained assume role in cyberduck/client
• documenation OIDC + bucket creation role + role chaining roles Admin Documentation for setting up OIDC Provider at AWS/MinIO and testing vault creation. #23

Open Questions

• when to switch from user attributes to resources ([Story] Scoped Access Tokens through Authorization Services / UMA #41)? Start implementation with user attributes.

Context

• Depends on/relates to Finalize vault storage configuration API #6.
• Preparations for shift7-ch/katta-clientlib#30 Hub frontend/client UI vault storage configuration for STS #3 HubIntegrationTest MinIO+AWS (no disabled container tests any more) #12
• Prerequisite for [Story] Scoped Access Tokens through Authorization Services / UMA #41

Implementation

[chenkins]

@ylangisc @overheadhunter @tobihagemann is it OK for you to use vaultId as bucketName when we create S3 buckets automatically for new vaults? This would keep things simple. Or do we need something more fancy like a hub-specific prefix to make the buckets recognizable as coming from the same hub for AWS admins? I suggest we store the bucket name in the vault config (resp. vault JWE, see discussion in #6) when we create the vault - this would allow to start with vault-UUID only and then add prefix or something if need arises without "touching" existing vaults.

[tobihagemann]

I'm also thinking about the S3 admins who might be wondering what these buckets are. I think a prefix with the product name would make sense and help with recognition. But since we don't have a product name yet, it's hard to define a prefix right now.

[overheadhunter]

While the vault id is unique and constant, I agree that a prefix might help humans.

[chenkins]

Summary of discussion with @ylangisc

Available keys for AWS web identity federation

You can use web identity federation to give temporary security credentials to users who have been authenticated through an OpenID Connect compliant OpenID Provider (OP) to an IAM OpenID Connect (OIDC) identity provider in your AWS account.
Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif

Likely interpretation: this list of keys=claims is exhaustive. See also:

Federated claims are not propagated into the AWS session and are not accessible in the trust policy.
Source: https://stackoverflow.com/questions/48492885/how-to-check-for-custom-openid-claim-in-an-iam-roles-trust-policy

And:

IAM and Cognito still does not allow you to use custom JWT claims in IAM permissions. This only works for a small subset of claims that Cognito sets by default like the Cognito user sub:
Source: https://repost.aws/questions/QUW1WibDWjQd2rOll4mDiPMA/federated-identity-authenticated-role-custom-claims

This rules the possibility to (0a) add separate custom claims <vaultID>: true or (0b) one custom claim "vaults": [>vaultId>...] to the token in AWS (the second approach (0b) would work in MinIO).

Furthermore, empirically if a list/set is sent in the aud claim, then trust policies are only evaluated against the first value in that list.

Currently, this leaves us with possibilities:

1. "mis-use" the amr claim, which supports set operations (ForAnyValue:...). The amr claim is intended for

Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used.
Source: https://openid.net/specs/openid-connect-core-1_0.html

2. Concatenate the vault IDs into one aud claim (string, not set/array of string) using a delimiter (e.g. | and then test in the trust policy using StringLIke operator (e.g. |<vaultId>|).

The first option has the advantage that the same setup can be used for AWS and for MinIO. Furthermore, for the second option we'd probably have to write a custom mapper and deploy it to Keycloak: https://stackoverflow.com/questions/60767085/keycloak-map-multiple-user-attributes

Can we run into problems with the first approach?

• Keycloak not under our control, different use of the amr claim?
• AWS not supporting the claim any more or evaluating the claims differently? -> minimal

[chenkins]

Complement: MinIO has no concept of trust policy and roles as in AWS, it has only two possibilities for OIDC STS:

• claim-based: you can specify a claim and all the values in the claim are mapped to a set of policies (so MinIO is more powerful in this regard in that you can activate multiple policies in one STS call, whereas in AWS you can assume only one role to which multiple policies can be attached (this attaching of policies to roles is static and cannot be done during trust policy evaluation)
• role-based: the OIDC token entitles you to assume the policy specified in the role_policy for the OIDC server configuration (probably, we could register separate OIDC servers in MinIO for each policy=vault going the the same Keycloak URL, to be tested)
  See: https://min.io/docs/minio/linux/reference/minio-mc/mc-idp-openid.html#mc.idp.openid.add

This rules out that we can evaluate a string claim in MinIO in StringLike manner, only verbatim matching.

-> use amr instead of aud for now.

[chenkins]

Complement for further reference:

aud for OAuth 2.0 Google client IDs of your application, when the azp field is not set. When the azp field is set, the aud field matches the accounts.google.com:oaud condition key.
Source https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html

-> if the azp field=claim is set, then aud in the condition is populated by the azp field and the values from aud claim go into oaud.......................

[chenkins]

https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use

I have an application that needs to talk to different resource servers

If a single application needs access tokens for different resource servers, then multiple calls to /authorize (that is, multiple executions of the same or different Authorization Flow) needs to be performed. Each authorization will use a different value for audience, which will result in a different access token at the end of the flow.

[chenkins]

• grant_type=authorization_code Authorization Code Flow aka. standard flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) --> with one auth, we'd like to have several tokens, though

• grant_type=password Resource Owner Password Flow aka. Direct access grants (https://auth0.com/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow) --> we do not want to hand over passwords to the client

• Hybrid Flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow/call-api-hybrid-flow) --> does not solve multiple access token problem

• grant_type=client_credentials Client credentials grant aka. service account roles (https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) --> not user-specific

• grant_type=implicit Implicit Flow

• grant_type=urn:ietf:params:oauth:grant-type:device_code Device Authorization Flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) --> we do not have input-constrained devices

• Implicit Flow with Form Post (https://auth0.com/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) --> to get an ID token, we need access token

• Authorization Code Flow with Proof Key for Code Exchange (PKCE) (https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce)

• grant_type=urn:openid:params:grant-type:ciba OIDC CIBA Grant

• grant_type=refresh_token

Can we do more with https://www.keycloak.org/docs/latest/authorization_services/#_resource_overview? Not sure yet.

[chenkins]

Another thread (thx @overheadhunter ): https://community.auth0.com/t/token-exchange-multiple-audiences/7188

https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use

I have an application that needs to talk to different resource servers
If a single application needs access tokens for different resource servers, then multiple calls to /authorize (that is, multiple executions of the same or different Authorization Flow) needs to be performed. Each authorization will use a different value for audience, which will result in a different access token at the end of the flow.

[overheadhunter]

Complement for further reference:

aud for OAuth 2.0 Google client IDs of your application, when the azp field is not set. When the azp field is set, the aud field matches the accounts.google.com:oaud condition key.
Source https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html

-> if the azp field=claim is set, then aud in the condition is populated by the azp field and the values from aud claim go into oaud.......................

Did using the azp claim make any difference?

[chenkins]

@overheadhunter I'll need to check empirically whether azp could be used with multiple values.

Strangely, the documentation says on the one hand

Define condition keys using the name of the OIDC provider followed by the claim (:aud, :azp, :amr, sub). For roles used by Amazon Cognito, keys are defined using cognito-identity.amazonaws.com followed by the claim.

On the other hand, azp does not appear in the list of available keys for AWS web identity federation...

amr is the only claim for which they explicitly say it's multivalued:

The key is multivalued, meaning that you test it in a policy using condition set operators

Reading this, I would guess it will only pass the first value into evaluation.

[chenkins]

Adding vault UUIDs to an ID token rather quickly reaches size restrictions (e.g. Serialized token too large for session), approx. 10-15 UUIDs. See also https://stackoverflow.com/questions/686217/maximum-on-http-header-values for header, however in our case it's in the body:

 <ErrorResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
  <Error>
    <Type>Sender</Type>
    <Code>PackedPolicyTooLarge</Code>
    <Message>Serialized token too large for session</Message>
  </Error>
  <RequestId>72a8a854-4a74-47f0-8e1f-e5f9cf145fb8</RequestId>
</ErrorResponse>

Approaches aka. Auslegeordnung

• live with this restriction
  • if we have vaults top-level, we might also have a restriction at the UI
  • in most cases probably not a problem....
• shorten UUIDs with the danger of collisions (some people could then have read/write access to the bucket, but they could not decrypt the data, and would only see the buckets if they get access to the ID token using dev tools and list buckets with the ID token)
  • still restrictions on the amount of vaults per user, maybe hard-to-predict ones and hard to balance ones.
• We find a way of using https://www.keycloak.org/docs/latest/authorization_services/#_resource_overview.
  • Highly unlikely to get an ID token this way, though.
• Instead of adding vault IDs to tokens, edit/create/delete roles on the S3 side when users are added/removed to/from a vault
  • vault owners would need to get (temporary) access to create roles;
  • users need to be given (temporary) access to to create buckets and roles (maybe restricted to some prefix);
  • in the end we would duplicate the roles in the hub tables on the AWS side (vault owners would need to be able to create and delete roles corresponding to granting access to the vault).
  • needs to be checked whether it is easy to design the roles so the users cannot do harmful actions
    • only create buckets, never delete should be feasible;
    • however, how to check only compliant roles are added;
    • still users could intercept tokens and create buckets/roles outside of hub as long as it complies with the defined restrictions.
  • organizations are usually reluctant to give away such permissions to users without central control/monitoring (e.g. through self service portal)
• ...?

@ylangisc request for comment: corrections, complements?

[chenkins]

Role limit: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html -> max 5000 per account. Not feasible approach in larger organization (10'000 users each having access to more than one vault).

Discussion with @ylangisc

• having AWS calls on every vault sharing is not KISS
• reduce IdentityToken size by removing roles etc. and using alternative to UUIDs (system millis, enumerating vaults starting from 0, ....) -> check out how fare we get with that, how many vaults can we squeeze in? Non-achievable max. upper limit 2048 / 32 = 64 when using UUIDs. This would also leave with one role per bucket and the corresponding IAM limit.

Interestingly, the following also uses the amr claim and discusses similar issues:
mozilla-iam/mozilla-aws-cli#26 -> https://github.com/mozilla-iam/auth0-deploy/blob/master/rules/AWS-Federated-AMR.js