Support for requiring a certain issuer of platform/accesstoken

[jonkjetiloye]

Description

Currently the AccessTokenRequirement and AccessTokenHandler only validate that the access token is issued by a valid issuer. This is done indirectly by using the issuer value to obtain correct public certificate during token validation.

For some internal endpoints it would be nice to be able to restrict access only for a specific platform component or issuer. AccesTokenHandler needs to perform a check for exact match on token issuer against approved issuers listed in AccessTokenRequirement. This is to be done before the token validation. Token validation is unnecessary unless the issuer is approved.

The change should be backwards compatible. This means the list of approved issuers can be empty and AccessTokenHandler should allow any issuers like today.

Example

POST accessmanagement/api/v1/internal/resources Is an endpoint in access-management which should be accessible only for the resource-registry application. Any other caller, even with a valid access token should be prevented access. Existing setup in Program.cs.

Development tasks

• [ ] Expand the IAccessTokenRequirement with a property for an array of allowed issuers
• [ ] Make necessary changes to AccessTokenRequirement
  • Constructor alternatives for no specified issuer, only one issuer and multiple allowed issuers
• [ ] Adapt logic in AccessTokenHandler to check issuer against the allowed issuers array
  • Empty array should result in the same outcome as today
• [ ] Write unit tests for the new functionality. There are existing AccessTokenHandler tests to take inspiration from.

[SandGrainOne]

@jonkjetiloye How critical is this?

[jonkjetiloye]

@SandGrainOne Currently not very critical. The endpoint we would like this feature for is not to be exposed through APIM, so will only be accessible through local cluster addressing.

It could perhaps become more relevant if we need/want to make endpoints accessible only for our own BFF component which is outside of the cluster. But I guess that could be solved in other ways as well, e.g. through subscription key access.