Say you have the following roles:
And the tenant in the URI is: tenant2
Expected output after Auth-N:
Expected output after Auth-Z:
X-Roles: role3, role4
The Identity token is not passed between the two filters.
We are going to start populating a new header called X-Map-Roles in the first filter, and the second filter will use that information to cull down the values in other headers including this header as well.
X-Roles is all of the roles that match any of the tenants that are being represented.
For the X-Tenant-Id, we want to be able to get tenants from the URI, a header, the body, or a query parameter, maybe even in the same request (e.g. one tenant from the URI and a second tenant from a header). For backwards compatibility, we will continue to support grabbing
the a tenant from the URI. We will also try grabbing a tenant from a header. The second part will open up the possibility of getting a tenant from the body or query parameter. When we match on multiple tenants, they will get the same quality (i.e. q=1 or whatever we default the quality to). The header that we look in for tenants will be configurable. The value will be assumed to be splittable. We should also validate the values in that header.
The tenant updates are being made in REP-6400 Resolved .
- The Auth-N filter will begin writing a new X-Map-Roles header with the full map of role tenants.
- The Auth-Z filter will overwrite the X-Map-Roles header with a trimmed down map of role tenants.
- We will begin getting as many tenants as we can (from the URI and configured header) and validating all of them instead of stopping at the first one found.
- Previously, we weren't necessarily getting all of the tenants.