I see the material in CVS now.
Had a look at the DTD and I like it.
I suggest we add <!ATTLIST SecurityContext children (true||false||yes||no) "true"
inherit
(true||false||yes||no) "true">
This first determines whether children of the class or action also are bound by the
constraints. Specified in the parent
object. The second determines if the children are bound to the parents constraints
when we specify constraints for the
children. By default parents constraints are applied to children, and children add
further constraints when we specify
them in the xml.
I also think we should also add a 'component' to templates and objects. For example we
may have a banking template name
"banking.vm" and it displays various information depending on whether a user has
access to bank records, view invoices,
see credit card info..
In this case we would have:
<SecurityContext template="banking.vm">
<description></description>
<component name="bank_records">
<group>.... </group>
</component>
<component name="view_invoices">
<group>.... </group>
</component>
It gives us finer grain control. The modified DTD is below:
<!ELEMENT Scope (SecurityContext+)>
<!ELEMENT SecurityContext (description, component)>
<!ELEMENT component (group)>
<!ELEMENT group (role*, permission*)>
<!ELEMENT role (#PCDATA)>
<!ELEMENT permission (#PCDATA)>
<!ATTLIST SecurityContext
id CDATA #IMPLIED
event CDATA #IMPLIED
template CDATA #IMPLIED
action CDATA #IMPLIED
class CDATA #IMPLIED
children (true||false||yes||no) "true"
inherit (true||false||yes||no) "true">
>
<!ATTLIST component
name CDATA #REQUIRED
>
<!ATTLIST group
name CDATA #REQUIRED
>
<!ELEMENT description (#PCDATA)>
I'm kinda busy right now so I don't have much time to look at the rest for about a
week, but feel free to post your
ideas in the meantime.
Cheers,
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]>
