CrossTenantAuthorizer is not async

[SteveHSX7]

Hi,

More of a question than an issue.

We're using the ICrossTenantAuthorizer to provide cross-tenant authorisation. We do have a grain that contains all the required information but as the IsAccessAuthorized() method is not asynchronous I can't use the grain methods to answer the question (I've tried numerous workarounds to invoke the grain async methods inside this non-async function but they all seem to just hang).

As a workaround we're writing the information in the grain to an external data source (Azure Table) but this is causing a few timing issues so I would much rather access the definitive source of information (i.e the grain).

Can the IsAccessAuthorized() be supplemented with an asynchronous version so I can (safely) invoke grain methods from it or do you have any suggestions as to how to solve this?

Thanks

[VincentH-Net]

Hi @SteveHSX7, thanks for the question - I will add that async callback in the next release and keep this issue open until then. You would need to think about perf in your use case though:

• The ICrossTenantAuthorizer is used in a grain filter that is invoked on every grain method call. As shown here it is valid to call a grain from an interceptor, however that could have a big perf impact on your entire system as it could add a network call to most grain calls - even for calls between grains that live in the same silo. Especially with more silo's and calling an auth grain that lives in a single silo - most calls would be network calls instead of in process calls, order(s) of magnitude slower.

In the current release, you can implement a slightly more complex but very performant and scalable alternative: keep the authorizer synchronous, but turn it into an in-memory cache that is kept warm with a push stream.

• your crossTenantAuthorizerFactory subscribes to the stream and retrieves it's state from the rights grain on silo startup and on changed message coming in on the stream. You can e.g. store it in a ConcurrentDictionary
  • Note that this is multithreaded code so guard against multiple simultaneous rights grain calls.
  • You have to decide what to do when the state is not initialized yet: probably allow specific grain types to be called or use some hardcoded / app configured rights
• the rights grain publishes a changed message on the stream when the rights are changed
• your infrastructure does not have to become more complex, as it is fine to use the in-memory stream provider for this: there is no need to persist stream messages when silo's go down