Feature to secure grains with authentication #8315
jan-johansson-mr
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
Orleans have kind of a support for securing grains via use of
RequestContext
, and filters, that enables to piggy back out-of-band data in the calls between the client and grains. I've been sketching on some infrastructure for Orleans to present a familiar feel to how security is used with ASP.NET Core.There are some caveats for the proposal, and I'd love your feedback. See at the end of this text.
First off, to enable security with the client side, we have the following pattern
The extension function
AddAuthentication
adds necessary plumbing withRequestContext
andOutgoingGrainCallFilter
.Then, on the host side, there is this pattern
Where
AddAuthentication
adds the nescessary plumbing withRequestContext
andIncomingGrainCallFilter
.Notice the
services.AddScoped<IClaimsTransformation, ClaimsTestTransformation>()
line, that adds the optional plugin of a claims transformer. The transformer can be usefull if there is a need to take the payload fromRequestContext
and transform to fullblown authentication context with the Silo.The grain interface is decorated with a
SecurityContextAttribute
, to help filter out grains that are using the security feature, like thisThe Silo host grain is then secured by the look and feel of the old good Authentication attribute, like this
Where the policy is plugged in from the policy statements at the silo builder section.
I've minimized the payload with the sketchy implementation, to only flow through three types
Here is the code that gets the values needed to populate
RequestContext
before putting the values on the wireAnd then vice versa the code that picks the values up
There is a type introduced, named
ISecurityContext
, that flows with the client and host, containing anIPrincipal
, the same pattern as used by ASP.NET Core with Http context and User property to flow the principal.The
ISecurityContext
is available with dependency injection, and opens up the following with the grainThe sketchy solution works really well in my testbed. However, there are some stuff that I'm not quite sure about yet
IClaimsTransfomer
, so again, one can have the option of plugging in the transformer, but not have the dependency to ASP.NET CoreOne tenet on this sketchy solution is to minimize
RequestContext
payload as much as possible, to avoid crunching too much, hence only flow a minimum set of data (possibly only "sub") and leave it to the transformer to do the heavy lifting once the grain has received the call.Another tenet is to use
ClaimsPrincipal
, to have an already established framwork powering this solution.Yeah, that's it, thanks!
Beta Was this translation helpful? Give feedback.
All reactions