http request from client app

[bsenthilr]

Exploring a POC on custom authentication path which requires to invoke an REST API to another container on the same pod (localhost). Assumption is the authentication phase is pre transaction execution hence is valid. Please suggest if thats not the case.

Are there any libraries on CCF that can be leveraged to invoke HTTP request?

Not familiar with openenclave, but enclave restricts socket connections from cpp-httplib even when linked to enclave target or with an application level socket based HTTP request.

Do these require additional openenclave call mappings to be setup ?

Any suggestions would be helpful.

[eddyashton]

Hi @bsenthilr,

Assumption is the authentication phase is pre transaction execution hence is valid. Please suggest if thats not the case.

Authentication also depends on the current KV state (ie - it may read from the KV to determine the caller's current auth status), is executed as part of the same transaction, and hence has the same expectations as any other code running inside a CCF handler. It should (generally) compute something that's purely determined by the KV state and incoming request (not un-attestable data retrieved from elsewhere), and must execute synchronously (and reasonably quickly, as long blocking periods will stall other requests).

There are a few escape hatches you can explore to do this:

• CCF has an "async host processes" subsystem that can be used to trigger some process on the host. That allows arbitrary side effects, but to get any data back into CCF you'll still need the external process to make an additional call.
• If your auth is (or can be coerced towards) OpenID/JWT-based, then CCF has another subsystem which can auto-populate this - you configure some metadata about the IdP and tell CCF to auto-refresh. So periodically (outside of the request execution stack), a CCF node will run an async process to fetch the latest issuer key from this IdP.
• There is an old openenclave-curl branch that got curl building in a way that could be linked against an openenclave enclave. Maybe it could be linked against a CCF enclave and called from a handler to make a HTTP request? This is extremely untested.

The simpler solution is to redesign this so that CCF doesn't need to call out - have some external system pushing data in to CCF. That way you get a clearer auth story (how does the process pushing this data authenticate itself?), and a clearer transactional audit story (what state did CCF use for a later auth validation? Whatever was written to the KV at that time).

[bsenthilr]

Thanks a lot @eddyashton this is very helpful.
We rely on KID/JWKS settings for Auth this is for a temp workaround which we anticipate to resolve later this year and mostly related to metadata fetching which is a workaround.
Agree with your recommendation and will evaluate to minimize callouts which is an antipattern.
Will also review and try out the async processing.