You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Bert van Brakel <be...@yahoo.com> on 2002/02/16 00:49:38 UTC
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" <Sw...@rippe.com>
To: "'Turbine Developers List'" <tu...@jakarta.apache.org>
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>