Thanks, sounds interesting, I'll have a closer look at it. On Friday, 18 March 2016 00:13:51 UTC+1, Carlos Dañel Ferreyra wrote: > > I believe the tracing module <http://kamon.io/core/tracing/core-concepts/> > of Kamon <http://kamon.io/> can help you here. > After authentication you should dispatch the first message within a new > tracer context, Kamon will ensure that context is propagated to all actors > involved. > > El jueves, 17 de marzo de 2016, 17:17:30 (UTC-3), Ryan Tanner escribió: >> >> Don't pass auth info into the *system, *pass with with each message into >> the *actor*. When a request comes in and its identity is authenticated, >> pass that authentication along with your messages. Then, if needed, let >> your actors figure out authorization based on that authenticated identity >> with whatever requirements are necessary for that component. >> >> This avoids both the ThreadLocal issue *and* makes it trivial to scale >> that across nodes—you pass whatever information is required all the way >> through your application. So long as it's serializable, it doesn't matter >> if those messages cross your cluster or stay local. >> >> On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote: >>> >>> Hi Konrad, thanks for the heads up. >>> >>> Good point, I will also ask around in the Spring community. >>> >>> It can be looked at, however, as a general question of security in a >>> Akka system - how can I pass user identity information into a Akka system >>> so that it can be picked up by any Actor receiving messages? After thinking >>> a bit about it, it's of course not that straight forward - even if I'm able >>> to bring the Spring SecurityContext onto each thread in the Akka system (by >>> overriding the ExecutionContext ( >>> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what >>> should be happening when an actor is actually executed on a remote machine? >>> >>> So my question for this community is: How is identity passed into an >>> Akka System? Or put differently, how do you solve the issue of >>> authorization within an Actor? As an Actor is responsible for the state of >>> a certain resource, it is also its responsibility to make sure to block >>> unauthorized users to change its state. >>> >>> Best Regards, >>> Bernd >>> >>> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote: >>>> >>>> Hi there Bernd, >>>> I think this is more of a Spring Security question... I don't really >>>> know if those strategies they provide work in such contexts. >>>> >>>> In general you could ask such question on a Spring group and explain >>>> that the context needs to survive being used >>>> from one thread at a time, but it could be a different one each time. >>>> Anything ThreadLocal based generally will not work (in any kind of >>>> async toolkits, not just Akka). >>>> >>>> -- >>>> Cheers, >>>> Konrad 'ktoso’ Malawski >>>> <http://akka.io>Akka <http://akka.io> @ Lightbend <http://typesafe.com> >>>> <http://lightbend.com> >>>> >>>> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote: >>>> >>>> Hello All, >>>> >>>> we have a small service that implements a REST API, and we use Akka to >>>> enable concurrency, for structure and readibility of our code. All works >>>> fine, except I'm struggling now with our security integration. We're using >>>> Spring as our 'container' framework and Spring Security to handle >>>> authentication and authorization. My question now is: How can I use >>>> >>>> String userId = >>>> SecurityContextHolder.getContext().getAuthentication().getName(); >>>> >>>> in our actors? I know that the Spring security context is by default >>>> put into a ThreadLocal. One idea I had is to create an ExecutionContext >>>> and >>>> pass this to the Actor system create method, thus letting Spring create >>>> the >>>> threads, and using the security context passing strategy ' >>>> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if >>>> anybody has done this thing already. Thanks in advance! >>>> >>>> -- >>>> >>>>>>>>>> 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 akka-user+...@googlegroups.com. >>>> To post to this group, send email to akka...@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/akka-user. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>>
-- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
