1. Topics
  2. Musings about passing SecurityContexts between threads

Musings about passing SecurityContexts between threads

Ed Warnicke (eaw) <eaw@...>
 

Guys,
At the AAA meeting this week, as Liem was walking us through the code, he showed us attaching
security context to an InheritableThreadLocal store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and executors where you may pass
work from one thread to another, but not by spawning new threads. I had mused about that being worrisome
to me, because it requires folks to get it right at many many places in the code every time work is passed between
threads, but that I didn’t have a smarter idea, and that might be the state of what could be done. (which is to say, as a matter of personal
technical opinion I made mild grumbly noises, but couldn’t be constructive about helping to move things
forward and so appropriately didn’t press it much past making my grumble known ;) ).

I still don’t have a better way… but was curious if other folks had any thoughts/experience to share as to
other options and the tradeoffs in them?

Ed
Kent Watsen <kwatsen@...>
 

I missed that meeting and thus don't have context, but my first question
is why do you need to do this at all? That is, in my world-view, the
incoming northbound request is steered to the appropriate service for
processing. That service is responsible to enforcing access-control, and
does so without other services needing to do any additional enforcement.

For instance, let's say you have a service that can generate pretty CIO
reports off data persisted by an analytics service. Furthermore, let's
say that the particular user sending the request is only allowed to see a
subset of the data (e.g. tenant=="pepsi" && device-type=="firewall"). So
we might have:

User Reporting Service Analytics Service
| | |

| | |
| | |
| Generate report | |
| over all data | |
|------------------>| |

| | |

| | |

| | Get data where |

| | tenant=="pepsi" && |
| | device-type=="firewall" |

| |------------------------->|

| | |

| | |



So no need for an internal call to pass a security context. Can it not
be the same here?


Thanks,
Kent

On 6/13/14, 4:10 PM, "Ed Warnicke (eaw)" <eaw@...> wrote:

Guys,
At the AAA meeting this week, as Liem was walking us through the code,
he showed us attaching
security context to an InheritableThreadLocal store (meaning, its context
is the thread or its children).
We talked a bit about how that interacts with thread pools and executors
where you may pass
work from one thread to another, but not by spawning new threads. I had
mused about that being worrisome
to me, because it requires folks to get it right at many many places in
the code every time work is passed between
threads, but that I didn¹t have a smarter idea, and that might be the
state of what could be done. (which is to say, as a matter of personal
technical opinion I made mild grumbly noises, but couldn¹t be
constructive about helping to move things
forward and so appropriately didn¹t press it much past making my grumble
known ;) ).

I still don¹t have a better wayŠ but was curious if other folks had any
thoughts/experience to share as to
other options and the tradeoffs in them?

Ed
Robert Varga -X (rovarga - Pantheon Technologies SRO@Cisco) <rovarga@...>
 

I think that would call for a set of implementation which will talk to the ThreadLocal context, e.g. ExecutorService.submit() would look at the store and attach the current context to the work being submitted and restore it when a thread picks up the work... It should not be hard to create such a decorator.

Bye,
Robert

-----Original Message-----
From: Ed Warnicke (eaw)
Sent: Friday, June 13, 2014 10:10 PM
To: aaa-dev@...
Cc: Kent Watsen; Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
Cisco); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco);
Nguyen, Liem Manh
Subject: Musings about passing SecurityContexts between threads

Guys,
At the AAA meeting this week, as Liem was walking us through the
code, he showed us attaching security context to an InheritableThreadLocal
store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and
executors where you may pass work from one thread to another, but not by
spawning new threads. I had mused about that being worrisome to me,
because it requires folks to get it right at many many places in the code
every time work is passed between threads, but that I didn't have a smarter
idea, and that might be the state of what could be done. (which is to say, as
a matter of personal technical opinion I made mild grumbly noises, but
couldn't be constructive about helping to move things forward and so
appropriately didn't press it much past making my grumble known ;) ).

I still don't have a better way... but was curious if other folks had any
thoughts/experience to share as to other options and the tradeoffs in
them?

Ed
1 - 3 of 3