Identity Server 4 is EOL since 13th December 2022
thomashilzendegen opened this issue · 3 comments
As announced on 13th December 2022 Identity Server 4 is not maintained anymore (see https://github.com/IdentityServer/IdentityServer4#important-update) and the repository was archived. Should we drop any code regarding this project and remove all references to it?
This may affect #408, too.
We asked this already before settling with IdSrv 4 ;)
We have two relative clear alternative options:
1.) Stick with OAuth. This would mean we need to replace the IdSrv 4 with another OAuth-capable component. At the moment we only know of OpenIddict. This project is maintained by a single person we don't really know. This would also mean that we need to write additional code to make OpenIddict a) work with our "OAuth Client database" (Tenants and their secrets) and also b) at least re-do the signing credential rotating part on top of OpenIddict (it does not support that out of the box and the interfaces are incompatible).
2.) Don't use OAuth as the default anymore.
Instead of using tenant/client name and secret at an IdP to exchange them for a token (that carries the tenant Id), we can use tenant name and the secret directly for auth at the RelayServer (like an API key).
The RelayServer would need to look that up to the tenant id and tenant config (i.e. tracing) at every request (so we need to implement a caching Auth handler that does the lookup). This would in fact greatly simplify the overall setup of the relay system as we can eliminate the need for an IdP completely. Using OAuth would still be possible by configuring an alternative authentication handler and setting up an IdP that provides the Tenant Id as the subject identifier.
I guess @marcofrodl would need to decide on the alternative and - more important - find some time slots to do that transition. ;)
Idea to resolve this:
In the DiscoveryDocument, add an AuthorizationType. New default is APIKEY, other valid value is OIDC.
If the value is OIDC, the connector and the server works like now.
Connector:
If the value is APIKEY, the connector does not fetch a Token from the authorization server.
Instead, it directly fills the Authorization header with the value ApiKey {TenantName}:{ApiKey}
Where the tenant name is the configured tenant name (which would be used as client_id for OIDC) and the apikey is the configured tenant secret (which would be used as client_secret for OIDC).
This means, no connector configuration needs to be touched, it simply stays the same.
Server:
Instead of configuring JwtBearer auth for the "relayserver" authentication scheme, we configure our new ApiKey authentication provider. For evaluating the header on the server side, we use the basic approach from the current Management Api Api-Key auth.
The authentication handler then checks for the Authorization Header and if it starts with ApiKey. If yes, it will split the upcoming string at the first colon (:). it will then do the same check as the IdSrv look up the ClientSecrets in the current db for the given tenant name and check if one of the values matches the SHA512 or SHA256 of the provided apikey (same code as in RelayServerTenantStore for loading the secrets and same code as in IdSrv4 for validating the client credentials).
It will then create the principal based on the same claims as the RelayServerTenantStore currently does (sub = Guid of the tenant, name and display_name from database).
The auth handler should cache this info for at least the same time as we currently cache the tenant info so that we don't need a DB access for every request a connector makes against the Relayserver.