hyperledger
Callback - OAuth protection
Currently the callback approach allows for the use of an api-key with callbacks:
--webhook-url <url#api_key>
We need to look at tightening this up by adding OAuth2 based authentication. Has anyone looked at this already?
Multitenancy already uses JWTs to authenticate tenants, however I don't think the pattern is as tight as a standard OAuth2 approach would require (long expiry time for tokens, no refresh tokens - callers just need to obtain new valid token using the old one or wallet id/key, etc.).
I need to think about it more, but my gut feeling is that OAuth2 authentication would make a good candidate for a plug-in: the functionality would be interesting/beneficial, but am reluctant to think about it as a "core" ACA-Py feature. A plugin could pave the path to extract multitenancy code as well into a plug-in, provide better token handling and support verification of signatures for tokens issued by an external authority (i.e.: not ACA-Py issuing the access token, but a different system, such as a IAM).
Totally agree on doing it as a plugin. Intriguing to put something core like multi-tenancy into that. Have to understand that a bit more.
@darrellodonnell — do you have an dev capacity to collaborate on this?
I thought we might have dev time/dollars, but that has changed. For now, we're considering restricting the use of ACA-Py to the same VNet as other services, as that will meet the security (SOC2) needs. However, I am intrigued with how adding OAuth here could help extend into different use cases.
Linking to #2029 that proposes securing webhooks by signing them based on tenant provided keys. This is the approach that Github uses to secure webhooks.
The core difference is that with Oauth the onus is on ACA-Py (issuer service) to manage authentication to the tenant. With the signed webhooks, the tenant manages the keys and validation of the messages which may provide better operational scalability. On the other hand in an enterprise setting the tenant may require Oauth as it is a standard or what their tooling supports.
@darrellodonnell not sure if the signed webhooks approach fits your business and security requirements. A plugin was developed for this approach. The plugin required a patch to ACA-Py specific to the plugin which did not feel like the right approach - better to implement directly in ACA-Py.
@tbloomfi that signed approach definitely sounds more effective than the current api-key approach. I'll take a look, though our team is moving ahead with "in the vnet" approach. many thanks Tim.
I like the signed webhook approach: the idea of having OAuth as a plug-in was, at least partially, because of the overhead (in code and processing) required to manage authentication to the tenant, and having to maintain this functionality in the code.
Additionally, when discussing OAuth we will have to potentially consider the controller-to-acapy pattern as well, in particular scenarios where acapy would be checking tokens issued by a different authority (i.e.: authenticating with a IAM system and providing the access token for the service to be consumed). I think it might become pretty big pretty quickly.