[jboss-as7-dev] On security context and propagation

[David M. Lloyd]

On 03/04/2013 12:32 PM, Bill Burke wrote:
>
>
> On 3/4/2013 12:16 PM, David M. Lloyd wrote:
>> On 03/01/2013 01:10 PM, Bill Burke wrote:
>>>
>>>
>>> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>>>> So for entry to the server making use of HTTP and SASL based
>>>> authentication backed by an IDM instead of JAAS and then converting the
>>>> loaded identity into a Subject does sound good.
>>>>
>>>> One point to keep in mind that is different from the JAAS population of
>>>> Subjects however is that the IDM approach is not currently expecting to
>>>> load roles pro-actively for an identity, instead it is expecting to
>>>> respond to isCallerInRole type checks as and when role checks are
>>>> required.  Applications however do have a finite set of roles used so
>>>> there are options here.
>>>>
>>>
>>> Not sure what you're saying here, but the IDM API needs to be able to do
>>> more than isCallerInRole().  See my previous examples.
>>
>> I think that the next step in exploring this idea would be to figure out
>> exactly what this would mean - how to integrate with, or replicate, our
>> existing IDM API(s), what we need to be able to store on/get out of the
>> security context itself - basically start with use cases and move on to
>> requirements from there.
>>
>> Bill had good examples of propagating bearer tokens between EJB and REST
>> or other services, and I think he's asking the right questions.  Keeping
>> in mind (and leaving aside) that this may or may not be appropriate for
>> AS 8, what other use cases and requirements are there for the security
>> context itself?
>>
>
> I don't understand why you'd even consider taking a step backwards.  The
> AS7 SecurityContext (via Picketlink) already has the ability to get and
> set role mappings and permissions.  This provides a large measure of
> flexibility and allows developers to implement custom security protocols
> through standard components i.e. servlet filters.  The IDM API should be
> for fetching security metadata, thats it.  I don't see why you'd want
> the IDM API to be anything more than that.

All I'm basically talking about is replacing SecurityContext's internal 
mechanism with the JDK AccessControlContext; that's really it.  The 
question is really about how to replace the stuff that was previously 
internally stored on the thread local (and the thread locals of other 
projects that reinvent this particular wheel), and the range of possible 
answers isn't that huge: it amounts to using the Subject's private data 
fields in various ways.

We need to do this if we want to support Subject.doAs() in some 
consistent manner (a bunch of frameworks we consume already use this, so 
the state of our security integration - especially with an SM present - 
can only be described as "spotty and weird").  It also makes integration 
easier (especially with these frameworks) for the reasons I laid out in 
my original email, and works nicely with the new SecurityManager 
requirements in EE7.

The fact is, the way we manage security context is weird and ad-hoc 
without any good reason for being that way.  Because of this we end up 
paying a cost in memory usage and performance, not to mention the 
leaking security context bugs that crop up from time to time.  Anil 
pointed out that even Scott wanted to change over to support 
Subject.doAs(), but never quite got around to it.

The desirable end state would be to either be able to use the same APIs 
(or at worst, equivalent APIs) that we had before.  But without 
understanding how they're used today we'll just end up running into 
trouble.  There's never any downside to gathering information, in any case.

-- 
- DML