On Monday 15 December 2003 04:52, Stephen McConnell wrote: > Niclas Hedhman wrote:
> Just put the security context into a thread local variable. Typically > this is going to be a principal. Say javax.security.auth.Subject... > The service manager implementation can > handle the determination if pricipal is required or not - and do the > autentication and access contol if required. Can it?? This is one thing I have tried to twist my head around. How does it know which User it should execute as? AFAICT, only the caller could possibly know that, no? Would also need a hook for the CallbackHandler somewhere as it would be the "client code" that provides it. (Hmmm, some thoughts required here...) > Method level access control could be moved to the proxy. I.e. no need > to do AccessController.checkPermission - we can takie care of that > automatically using metadata available on the container side of the > equation. I initially thought that too, but decided against it for one reason only; Component Documentation!! The Component Author will be required to add a section of Security Permission Requirements, and IMHO it should include everything. And if part of the requirement is hidden in the Proxy, the CA will forget to document it, and users will be somewhat confused. <snip content="record protection example" /> > Imoportant question - how much of this can be moved to metainfo on methods? Yes important question. But my conclusion is that there is a definate need of runtime computed "required permissions", such as the PrimaryKey example shows. > >And then we would need a new SecureSecurityManager and understand the > >SecureServiceable interface signature... > > Ummm, not sure - should be able to handle this without distrupting > interfaces or supply info to the component. I have been digging for alternate solutions via the LifeCycle extension mechanism, and might come up with a proposal later. Right now not sure it complete security-agnostic Framework will cut it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
