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

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.