You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Weaver, Scott" <Sw...@rippe.com> on 2002/02/16 21:10:01 UTC
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:bertvanbrakel@yahoo.com]
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" <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>
Re: Security Changes - Prevention of hardcoding security [Spinoff: Re: Security Changes (3 of 3) -... ]
Posted by Bert van Brakel <be...@yahoo.com>.
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" <Sw...@rippe.com>
To: "'Turbine Developers List'" <tu...@jakarta.apache.org>
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:bertvanbrakel@yahoo.com]
> 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" <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>
>
_________________________________________________________
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>
Re: Security Changes - Prevention of hardcoding security [Spinoff: Re: Security Changes (3 of 3) -... ]
Posted by Bert van Brakel <be...@yahoo.com>.
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" <Sw...@rippe.com>
To: "'Turbine Developers List'" <tu...@jakarta.apache.org>
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:bertvanbrakel@yahoo.com]
> 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" <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>
>
_________________________________________________________
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>
Re: Security Changes - Prevention of hardcoding security [Spinoff : Re: Security Changes (3 of 3) -... ]
Posted by Eric Dobbs <er...@dobbse.net>.
On Saturday, February 16, 2002, at 01:10 PM, Weaver, Scott wrote:
> 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.
Scott,
Sorry I didn't respond earlier. I just committed your code into a
folder in the rundata_security_changes branch in this directory:
./proposals/scott/security
Hopefully that'll facilitate the conversation between you and Bert.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>