Hi Endre, Thanks for the reply. Apologies for the misleading comment in the end of the first post, about using the resolver function. I understand that function would be called on the shard proxy which is not what I would intend, so that makes it a no go as a solution. I would need authorization to happen on the node level where the shard region actor would reside, probably before the shard region actor is actually created. The intent like I mentioned would be for having the authorization as close to the data access as possible.
Like I've mentioned before, having to deal with a gatekeeper entity would mean not leveraging the direct cached connections between the shard proxy and shard region, and consequently adding additional layers of network IO and JVM overhead. The gatekeeper does not have to be a cluster singleton. One option might be to launch it on every data access node and use routing to talk to it. I haven't made any further iterations but any other suggestions will be very welcomed. tnks, Rod On Wednesday, January 20, 2016 at 12:22:46 PM UTC, Akka Team wrote: > Hi Rodrigo, > > I think it is the Gatekeeper approach that works best here, but I don't > understand why you think that it has to be a cluster-wide singleton (is a > hidden requirement/constraint missing somewhere?). If it is possible to do > your evaluation in the resolver function that for me suggests that you are > able to decide the validation locally. I would suggest that instead of > communicating through the shardRegion actor, create a singleton actor > locally to the system that "wraps"/proxies-to the shardRegion actor > emulating its interface but evaluating your constraints. > > -Endre > > > > On Tue, Jan 12, 2016 at 9:01 AM, Rodrigo Boavida <[email protected] > <javascript:>> wrote: > >> Hi all, >> >> I'm currently implementing an Akka Sharding based infrastructure and >> found a limitation with the solution that potentially becomes a security >> problem. >> >> There is the web layer (Play) and the data access layer of the akka >> cluster. The web layer communicates through Akka Sharding proxy with >> sharded data query actors - one for each topic (topic name will be in the >> resolver). >> >> To avoid random invalid query actors to be created through sharding by >> any cluster entity, I would like to validate upfront before the sharding >> actually occurs if the shard region and entity identifier are actually >> valid against my system configuration. >> >> As a matter of principle I would prefer to implement the validation of >> the sharding identifiers on the actual data access layer (the sharded >> layer), the closer to the data, the better. >> >> The problem with this approach is that it seems I have no control over >> the shard region actor and the entity actors creation. What I would need is >> to have some kind of exposure from the sharding API that would allow me >> introduce this validation and have a reply back to the web layer if an >> invalid identifier (shard or entity) is being queried BEFORE the actual >> shard actor gets created somewhere on the cluster. >> >> I have thought about using a Gatekeeper kind of layer on the data access >> layer to introduce the validation, but I believe I would be just moving the >> problem from one place to another: >> 1 - Would still be missing authorization on the end receiver node of the >> request, since Akka sharding communication would be the same from the GK to >> the data query topics >> 2 - "Man in the middle" would be adding network connection overhead - >> instead of reusing the cached connection between the shardRegion proxy on >> the web layer and the shardRegion, on every request we would be potentially >> creating 3 new TCP connections assuming the GK is on a different JVM than >> the destination >> 3 - "Man in the middle" adding unwanted CPU and Heap overhead with IO >> marshaling and corresponding GC on both the GK JVM and the end data access >> JVM >> 4 - We wouldn't be really leveraging the balancing nature of akka >> sharding by adding this tunnel layer, neither the smart way akka sharding >> manages connections >> >> All of this to say that would really like to go with some customization >> of akka sharding. I have thought about making the shard and entity resolver >> functions return something invalid that would invalidate the creation but >> is that really possible and would I be able to manage it all the way up to >> the caller? >> >> thanks for having the time to read this and in advance for any comments >> or suggestions. >> >> tnks, >> Rod >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > Blog: letitcrash.com > Twitter: @akkateam > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
