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

[Bill Burke]

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.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com