OK, some ideas, which may progress the discussion. I assume the SECURITY object is a singleton (one instance).
What if each plugin inherits from an abstract class, within that class there is a public (sealed) method AssignRole, which accepts a Role object, which is available as a protected get property AssignedRole. This property is used to query what can be accomplished. AssignRole takes two parameters, some dynamic string (e.g. a guid or something similar) and a Role object. As part of the AssignRole process the method validates with the SECURITY singleton that this is an allowed role for this instance using the dynamic string (key) and the PLUGIN object. This assumes that the SECURITY object keeps track of Roles, dynamic keys, and PLUGINS. Maybe each Role is assigned a dynamic key, which can only be validated and used with one instance of a plugin. ----- Original Message ----- From: "Janis Braslins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 7:16 PM Subject: [ADVANCED-DOTNET] Design Puzzle > I am in a bit of a bind here. If you have a few minutes, perhaps you could > help me out with this architecture design issue. > > > SPEC: > > 1) We have a central object/assembly that has permissions to access certain > elements that no other object of the application can. We call it SECURITY > object. > > 2) We have numerous objects compiled and invoked at runtime that will be > performing calls to the SECURITY object. We refer to them as PLUGINS. The > source of every PLUGIN is assumed to be "unsafe". When each PLUGIN is > compiled into assembly, it's FileIO/Registry and other sensitive > permissions are being refused. The intention is to let the PLUGINS access > sensitive information via SECURITY object. > > 3) SECURITY object is tasked with compilation of PLUGINS at runtime. It's > important to note that multiple instances of the same PLUGIN will be able > to coexist at the same time and operate independently. > > 4) When an instance of a compiled PLUGIN is being created, SECURITY object > must assign it a certain role based on numerous external parameters not > contained within the PLUGIN source. Those roles determine what functions of > the SECURITY object those PLUGINS have access to. > > 5) The PLUGINS themselves should not be capable of changing their roles. > > 6) SECURITY object should be able to change the role of a certain > _instance_ of a PLUGIN at runtime when some external conditions are met. > > > PROBLEMS: > > 1) So, basically, we can't store the ROLE of the each instance of the > PLUGIN within the PLUGIN itself, as it would then be able to modify it's > own role. > > 2) We cannot use declarative custom security permission checks to limit the > role each PLUGIN gets, as each instance of the PLUGIN can have a separate > role. > > 3) We cannot use imperative custom security permission checks (I just don't > see how it would work, please correct me if I am wrong) > > > POSSIBLE SOLUTIONS: > > I've though of storing information regarding each instance of every PLUGIN > created and activated inside SECURITY object. But that means SECURITY > object should be aware of who the callers of it's methods are. > > We cannot require SECURITY object's methods to have a "caller" argument, as > PLUGINS would be able to obtain a reference to the other PLUGINS with > different roles, and pass those to the SECURITY object, faking their role. > > As far as I see, there's no way to obtain a reference to the caller object > via StackTrace/StackFrame classes, only reference to the caller type. Since > each instance of our PLUGIN can have a different role, that information is > not sufficient to determine callers role. > > I AM STUCK ... Ideas anyone? > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > NEW! ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
