Sure, sounds like a good idea. Feel free to post to me directly and we can see if we can thrash something out.
I think we should be approaching this security stuff from two directions. One is attaching permissions and things to user/groups and so forth, and the other applying security constraints to objects like templates, connections etc... I think the main focus has been on the former, so some work on the latter would be good. Bert. ----- Original Message ----- From: "Weaver, Scott" <[EMAIL PROTECTED]> To: "'Turbine Developers List'" <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 9:10 AM Subject: RE: Security Changes - Prevention of hardcoding security [Spinoff: Re: Security Changes (3 of 3) -... ] > Bert, > > I posted a full set of interfaces, concrete class example implementations > and dtds with example .xml files of my security stuff last weekend per the > request of Eric Dobbs. I have not heard much one way or the other on them. > If you would like I can repost it or send it to you directly. Maybe we > could combine efforts on getting this piece of the new security model > proposal in an acceptable state. > > The more transparent authorization can be made the better and the easier it > would be for someone to change the security implementations on the fly. > > Scott > > -----Original Message----- > From: Bert van Brakel [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 6:50 PM > To: Turbine Developers List > Subject: Security Changes - Prevention of hardcoding security [Spinoff: > Re: Security Changes (3 of 3) -... ] > > > I like this idea. I'm looking at doing something similiar myself. See my > draft proposal below if anyones interested. Something similiar to what Scott > does.... > > ----- Original Message ----- > From: "Weaver, Scott" <[EMAIL PROTECTED]> > To: "'Turbine Developers List'" <[EMAIL PROTECTED]> > Sent: Saturday, February 09, 2002 3:14 AM > Subject: RE: Security Changes (3 of 3) - Subject, Principal, Project details > > > I've actually already started using this in reverse. I have a service > based > > on an XML file that binds a set of Groups, Roles and Permission to a > > specific context. > > Currently I use it to prevent hard-coding required security into actions > and > > screens. The isAuthorized() method of screens and actions query the > > service to find out what security is required for that specific context > > (which could be a screen or action or just about anything). > > Sample config file > > <SecurityContext> > > <context name="Security.vm"> > > <description>Seceurity Maintenance</description> > > <group name="agora_system"> > > <role>user_maintenance</role> > > <permission>change</permission> > > <permission>add</permission> > > </group> > > </context> > > </SecurityContext> > > The following is something I have in mind: > > What I propose we have: > > 1. Secureable objects (a Action,Template, other class objects) > 2. which have Component(s) which we want to secure (like a > method, part of a page,...) > 3. which are dependent on constraints > 4. which are enforced through a > SecurableSecurityManager( SSM) service > > The SSM interface would have the following method: > > isAuthorised(Object, componentName, RunData) > > All securable classes would be encouraged to implement the securable > interface: > > interface securable(){ > Collection getComponents(); > } > > This would return a collection of component names so we could use a gui (ie > template) to query all the classes and see what we can assign constraints > to. The SSM could either be set to allow all unregistered components to be > athorised, or not. That is up to the implementation. > > ********************** > For Example: > > Actions we want to secure could inherit from 'SecurableAction' > > abstract SecurableAction extends Action { > public boolean isAuthorised(componentName, RunData){ > return SSM.isAuthorised( this, componentName, RunData ) > } > } > > And in PermissionAction we could have: > > Permission action extends SecurableAction {.... > doInsert(data,context){ > if( isAuthorised( "insert_pemission", data) ) > blah... > else > print( go away ) > } > } > > Templates could be secured using: $ssl.isAuthorised( <templateName>, > "view_bank_records", $data ) > > The configuration for the SSM could be an XML file, but because it is a > pluggable service could implement its own storage method > > Example Format: > <access-control> > <secureable type="class||screen" name=""> > <component name=""> > <constraint > type="user|scope|project|group|role|permission|SSL" name="[name of the > user/scope/principal/subject...]" > > <constraint type=... ></constraint> > </constraint> > . > </component> > . > </secureable> > . > </access-control> > > Specific Example: > > <access-control> > <secureable type="class" > name="com.mycompany.actions.PermissionAction"> > <component name="insert_permission"> > <constraint type="group" name="administrators"> > <constraint type="permission" > name="modify_security_settings" ></constraint> > </constraint> > </component> > </secureable> > <secureable type="screen" name="/strongscreens/admin1.vm"> > <component name="view_invoices"> > <constraint type="SSL" name="true"> > <constraint type="group" > name="administrator"> > <constraint type="role" > name="accounting" > > <constraint > type="permission" name="view_bank_records" ></constraint> > </constraint> > <constraint type="role" > name="root"></constraint> > </constraint> > </constraint> > </component> > </secureable> > </access-control> > > Therefore a user would have to belong to the 'administrators' group and have > the permission 'modify_security_settings' to be able to access or invoke the > 'insert_permission' component (in this case a method). > > In the second example a user would have to have a SSL conection and belong > to the 'administrators' group, have the role 'accounting' and the permission > 'view_bank_records' OR have the role 'root' in the same group to access the > 'view_invoices' component. . > > Could eventually even add a 'time of day' or 'day of week' etc in for > constraint type. I'm looking at getting SSM to throw an security exception > which explains the problem, like "not using SSL", or "does not have > permission" .... > > The whole of this exercise though is to allow dynamic access control to > parts of the system (app or site) in the most flexible way possible. This > system doesn't really care what security model we use as we supply our own > implementation. Whether we use subject/principal/group/role/permission > access control is irrelevant. > > The default SSM *could* use principle/scope/role/permission as it seems > things are kind of headed that way. The implementation just grabs what it > needs from the RunData object. > > Anyway that's the way I'm heading. For now I just have a SSM which always > returns true while I work out the details. > > Bert. > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
