In JWT-like authn/authz mechanisms, some forms of ACLs are directly embedded in the token. This information will be used during pub/sub for access control. In the current workflow, the ClientInfo of each session, which is populated after a successful connection, only contains limited reserved metadata. This makes the implementation of JWT-based auth provider plugins really challenging.
Possible solution
Enhance the OK proto (the returned type when the connecting client passes authentication) to allow the passing of additional implementation-specific attributes describing the current authenticated client. In the JWT case, the ACLs will be attached as additional attributes.
Populate the ClientInfo with these attributes as part of the metadata, ensuring the reserved metadata is not overridden. In the JWT case, the ACLs information will be treated as metadata and used in pub/sub permission checking, which can likely be done locally without the need for remote calls.
Notes
There is no limit on the size of the attributes passed back from the auth provider plugin via the OK structure. It is the responsibility of the plugin implementer to keep the attributes compact and memory-efficient.
Problem
In JWT-like authn/authz mechanisms, some forms of ACLs are directly embedded in the token. This information will be used during pub/sub for access control. In the current workflow, the ClientInfo of each session, which is populated after a successful connection, only contains limited reserved metadata. This makes the implementation of JWT-based auth provider plugins really challenging.
Possible solution
Notes