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]>
