How to pass a Spring security context to all actors in a Akka system?

465 views
Skip to first unread message

Bernd G.

unread,
Mar 14, 2016, 8:21:11 PM3/14/16
to Akka User List
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!

Konrad Malawski

unread,
Mar 16, 2016, 5:01:36 PM3/16/16
to akka...@googlegroups.com, Bernd G.
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
Akka @ Lightbend
--
>>>>>>>>>> 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.

Bernd G.

unread,
Mar 17, 2016, 1:49:17 PM3/17/16
to Akka User List, bernd...@gmail.com
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

Ryan Tanner

unread,
Mar 17, 2016, 4:17:30 PM3/17/16
to Akka User List, bernd...@gmail.com
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.

Bernd Götz

unread,
Mar 17, 2016, 6:37:24 PM3/17/16
to Ryan Tanner, Akka User List
Hi Ryan, many thanks, your proposal makes sense to me, and I think I will take that approach.

On the other hand, I don't really like the idea to have the user id passed along as a member of my messages, like I don't think we should pass around the user id as method parameters in the non-Akka code. One more potential issue is 'rogue impersonation' - would it not be possible for an attacker to connect to my Akka system and send messages with -any- user id? How would I be able to protect my Akka system from something like that happening?

Anyway, as long as I have a local Akka system, things are safe, I guess.
Message has been deleted

Carlos Dañel Ferreyra

unread,
Mar 17, 2016, 7:13:51 PM3/17/16
to Akka User List, bernd...@gmail.com
I believe the tracing module of Kamon 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.

Bernd G.

unread,
Mar 18, 2016, 3:30:05 AM3/18/16
to Akka User List, bernd...@gmail.com
Thanks, sounds interesting, I'll have a closer look at it.

Konrad Malawski

unread,
Mar 18, 2016, 12:59:34 PM3/18/16
to Akka User List, Bernd G.
Having that said, we do have such mechanisms in place – that act "like a thread local, but across actors",
metadata can be transferred along with messages transparently using our Lightbend Monitoring infrastructure:

Here's an example which does so with MDC data, but it could do the same for security data:

So the tech is there, but we're not planning to solve the security thing right now.
If you'd like to know more or roadmap things you can ping sa...@lightbend.com (monitoring is a commercial offering).
Reply all
Reply to author
Forward
0 new messages