I realise this thread is almost 2 years old, but it's because of that that I was wondering whether the design patterns within still hold true.
Given UntrustedMode blocks remote deployment, PotentiallyHarmful messages and it prevents actor selection outside of the whitelisted 'receptionists', it seems to me as though this would be a reasonably safe model for communication with a potentially untrusted client ActorSystem. The docs still mention a locked down guardian 'remoting' ActorSystem, with a local 'protected' ActorSystem behind it, though the only reason I can think of that this would need to be the case is to prevent the accidental leakage of a 'protected ActorRef' to an untrusted client, since they could then potentially forge messages to the 'protected' system/bypass the receptionist/selection protection/etc. Is anyone able to confirm/deny this for me? Also, as an aside, has anyone come across a 'sandboxed actor' pattern (to prevent actors that are children of the 'sandbox guardian' from being able to select actors that are 'above'/parents to it, prevent PossiblyHarmful messages that would shutdown the ActorSystem, etc) Cheers Glenn / devalias On Friday, 28 September 2012 20:34:58 UTC+10, √ wrote: > > Roland also suggest putting the sensitive ActorSystem "behind" a > front-ActorSystem which is really tied down, so you do the > authentication/authorization there. > > Cheers, > √ > > On Fri, Sep 28, 2012 at 1:30 AM, √iktor Ҡlang <[email protected] > <javascript:>> wrote: > >> Hi Pete, >> >> the point of akka-remote is to provide scaling-out facilities and is as >> such based on a peer-to-peer mode where each node is considered to be >> trusted. >> >> It is definitely possible to implement your own security checks in your >> own custom RemoteTransport. >> >> Having said that though, I think you're right in the sense that >> untrustedMode should not allow deployments. >> I'll open a ticket to fix that. >> >> Cheers, >> √ >> >> >> On Thu, Sep 27, 2012 at 8:19 PM, Frost <[email protected] <javascript:>> >> wrote: >> >>> Hi, >>> >>> I would like to use akka to set up a client server architecture where >>> user facing client applications run akka locally and connect to the server >>> with remote actor references. However, it appears that when you use >>> akka-remote, the server becomes very insecure. For instance, you can >>> connect with a client and have it deploy an actor which runs remotely on >>> the server. I have tried constraining this using configuration settings >>> (see below), but they don't stop this from occurring. Ideally, I would >>> there would be some way of turning this off completely. >>> >>> It would also be nice if you could limit access to a set of "published" >>> actor references, otherwise clients could access actors which were meant >>> for internal use only, which is not ideal. >>> >>> It would be preferable if there were some sort of >>> authentication/authorization for remote actor systems that could be applied >>> on an ActorRef by ActorRef basis to constrain access to any given actor by >>> looking at the remote actor systems credentials to see if it is authorized. >>> If this information were exposed to the actors themselves, then they could >>> also use this information when determining how to respond to individual >>> messages. >>> >>> I don't currently see any way to do any of this, which leads me to >>> believe that I will have to disable akka-remote, and then wrap the client >>> and server actor systems in a custom networking protocol which will let me >>> marshal the messages back and forth between the actor systems using some >>> sort of custom security implementation. Having to do this seems to defeat >>> the point of having a module like akka-remote. It also makes using the >>> akka platform a much harder sell to my boss(es). >>> >>> It was really great how simple it is to setup remote actors and start >>> passing messages around with minimal/no fuss configuration... >>> >>> Some of the things I tried in my configurations: >>> >>> (in server's conf file) >>> akka.remote { >>> untrusted-mode = on >>> netty { >>> require-cookie = on >>> secure-cookie = "a cookie for testing" >>> } >>> } >>> >>> (in client's conf file) >>> akka.actor.deployment { >>> /onserver { >>> remote = "akka://[email protected]:2552" >>> } >>> } >>> >>> Please note, I tried this without the cookie's enabled as well as some >>> other combinations. >>> >>> I would have expected the untrusted-mode to block the local deployment >>> of an actor from a remote actor system, but it does not. >>> >>> Thanks in advance >>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>> >>>>>>>>>> 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 post to this group, send email to [email protected] >>> <javascript:>. >>> To unsubscribe from this group, send email to >>> [email protected] <javascript:>. >>> Visit this group at http://groups.google.com/group/akka-user?hl=en. >>> >>> >>> >> >> >> >> -- >> Viktor Klang >> >> Akka Tech Lead >> Typesafe <http://www.typesafe.com/> - The software stack for >> applications that scale >> >> Twitter: @viktorklang >> >> > > > -- > Viktor Klang > > Akka Tech Lead > Typesafe <http://www.typesafe.com/> - The software stack for applications > that scale > > Twitter: @viktorklang > > -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
