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.