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

[Anil Saldhana]

On 03/04/2013 01:30 PM, Bill Burke wrote:
>
> On 3/4/2013 2:17 PM, David M. Lloyd wrote:
>> 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.
> And all I'm saying is that ACC, as-is, is an incomplete API for our
> needs.  If you can extend this class, great.  From what you're saying,
> it sounds like using ACC would solve a few integration problems.
>
ACC is useful for threaded applications.  It works on a single thread - 
end to end.  If our
use cases are from client - ejb-rest  on a single thread, it works.  But 
if you desire
to have a generic security context api that may be session based in 
addition to thread model,  ACC does not work.