Authorizing user clients based on CA rather than end cert #2335
-
|
Dear team ccf, Suppose if a certain user client is already authorized to issue rpcs to a certain CCF app, we think it would be great if a second user whose certificate is signed by the first user could also issue rpcs to the same app (with similar rpc rights) without having to explicitly add the second user via the CCF consortium. We have a multi-institutional application, and the CCF consortium initially authorizes a single user cert per institution. The single-user acts as the front end for the institution and would like secondary users within the institution to gain the same rpc rights as the front end user, without further explicit approvals. Please let me if this is already possible within CCF today, or if this would be a new feature request. Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Hi @prakashngit, Although there is no built-in authentication built-in policy that does this now, it ought to be relatively straightforward to implement as a custom policy. The process is documented here: https://microsoft.github.io/CCF/main/build_apps/logging_cpp.html#authentication authenticate() has access to a read-only Tx and to the request context, so it should be a matter of looking up the right institution cert in the KV (by fingerprint perhaps?), and validating the caller cert chain. |
Beta Was this translation helpful? Give feedback.
-
|
@achamayou Thank you very much for the reply. Very interesting to learn that it is possible to implement this as a custom policy in CCF. (I am still stuck with my knowledge of version 0.11, need to update myself to the recent features). Thank you once again! |
Beta Was this translation helpful? Give feedback.
Hi @prakashngit,
Although there is no built-in authentication built-in policy that does this now, it ought to be relatively straightforward to implement as a custom policy. The process is documented here: https://microsoft.github.io/CCF/main/build_apps/logging_cpp.html#authentication
authenticate() has access to a read-only Tx and to the request context, so it should be a matter of looking up the right institution cert in the KV (by fingerprint perhaps?), and validating the caller cert chain.