1. Messages
  2. Musings about passing SecurityContexts between threads

Re: Musings about passing SecurityContexts between threads

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
Join z.archive.aaa-dev@lists.opendaylight.org to automatically receive all group messages.