Hi Divesh,
thanks for the input. Regarding your points:
One implementation point I think is worth clarifying is how apiGroup will
be represented internally. It may be useful to make it part of the REST API
model itself, rather than treating it only as a URL prefix, so the same
value can be used consistently by routing, OpenAPI generation, Swagger UI,
and security checks.
This was the idea, apollogies if i described it unclear.
The authentication and authorization design may also need some detail. If
tokens are API-group specific, the token should probably carry the apiGroup,
and request validation should reject a token issued for one group when used
against another group.
What I am thinking is hosting the authentication endpoint thats currently at
rest/auth/token
with a path parameter at
rest/{apiGroup}/auth/token
Inside the Method we then validate apiGroup against all known apiGroups
(if non match, log a warning and default to the default apiGroup) and
validate the user has correct SecurityPermission for the given apiGroup.
We create the token with the apiGroup as an additional key:value pair.
When validating the token its then simply an additional check if this
token was issued for this endpoint.
Best regards,
Lukas
