As described in the fertilesoil document on identity, subject identities should always be constrained to some tenant context to facilitate better access control and auditing logic. identity-manager-sts does not currently support this. However, RFC 8693 supports the use of audience and resource parameters for logical service names and URIs respectively, and we can leverage those to constrain a token to a given tenant. This implies that the STS supports some kind of binding between tenant nodes and individual issuers.
A few questions come from this:
- What does the management API for this flow look like?
- What makes more sense:
audience (logical tenant name) or resource (tenant URI)?
- Do we want to support issuing tokens that are valid for multiple tenants?
Ultimately a solution should preferably leverage existing RFCs rather than relying on custom claims or other such logic.
As described in the fertilesoil document on identity, subject identities should always be constrained to some tenant context to facilitate better access control and auditing logic. identity-manager-sts does not currently support this. However, RFC 8693 supports the use of
audienceandresourceparameters for logical service names and URIs respectively, and we can leverage those to constrain a token to a given tenant. This implies that the STS supports some kind of binding between tenant nodes and individual issuers.A few questions come from this:
audience(logical tenant name) orresource(tenant URI)?Ultimately a solution should preferably leverage existing RFCs rather than relying on custom claims or other such logic.