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

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.