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/08 15:14:56 UTC
RE: Security Changes (3 of 3) - Subject, Principal, Project detai
ls
How about Context? IMOHO, it has a more generic feel than Project.
Example(s):
In which context do these security values apply
- The Permissions Read, Write and View are used within the "Context" of a
content management system.
- The Permissions Close Portlet, View portlet are used within the "Context"
of Jetspeed.
> Just
> throwing out terms,
> feel free to ignore :-)
ditto
p.s.(and somewhat OT)
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>
If anyone is interested, I would be more than willing to donate the code.
Scott
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Friday, February 08, 2002 8:27 AM
> To: Turbine Developers List
> Subject: Re: Security Changes (3 of 3) - Subject, Principal, Project
> details
>
>
> On 2/8/02 8:04 AM, "Gareth Coltman"
> <ga...@majorband.co.uk> wrote:
>
> >> Yeah, Group is a bad name for this, Project is much better.
> >>
> >>> -Eric
> >
> > Yep, group confused the hell of out all the developers in
> my team. I ended
> > up just telling them to think about it as the domain.
> Project is also a bit
> > of a non-standard term though. Perhaps realm or something is better,
>
> How about the completely abstract term Resource. Just
> throwing out terms,
> feel free to ignore :-)
>
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
Security Changes - Prevention of hardcoding security [Spinoff: Re: Security Changes (3 of 3) -... ]
Posted by Bert van Brakel <be...@yahoo.com>.
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 (3 of 3) - Subject, Principal, Project details
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> How about Context? IMOHO, it has a more generic feel than Project.
I had suggested Context way back when, but it was pointed out that
this could cause name collisions with Velocity's Context.
> Example(s):
> In which context do these security values apply
> - The Permissions Read, Write and View are used within the "Context" of a
> content management system.
> - The Permissions Close Portlet, View portlet are used within the
> "Context" of Jetspeed.
> ...
> 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).
This is EXACTLY what I'm talking about when I mention Scope.
In fact, I'll go ahead and add the concept of Scope (unless someone
suggests a better name that is NOT Context) to my proposal.
> If anyone is interested, I would be more than willing to donate the code.
If the proposal catches on, I'll most likely accept your offer.
> Scott
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Security Changes - renaming 'Project'
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Well, context is great except there are already so many things called a
context. Velocity context, servlet context, do we really want another one?
But I do like the word.
What a funny thread this is.... ;)
Gareth
> -----Original Message-----
> From: Eric Dobbs [mailto:eric@dobbse.net]
> Sent: 08 February 2002 16:48
> To: Turbine Developers List
> Subject: Re: Security Changes - renaming 'Project'
>
>
> In an effort to speed the brainstorming along I thought I
> would offer this list of names I've seen and include a
> count of the recent "voters". I've added a couple more
> suggestions.
>
> Votes New Name Voters:
> -------------------------------------------
> 1 AuthorizationContext Eric
> 1 Context Scott
> 1 Domain Gareth
> Module
> PermissionContext
> Project
> 1 Realm Gareth
> 1 Resource Jason
> 1 Scope James
> SecurityContext
> Zone
>
> I personally think Context has the best fit but is used
> EVERYWHERE. Maybe one of the FooContexts would work.
> There are precidents: JAAS has a LoginContext there's a
> NamingContext in JNDI.
>
> -Eric
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes - renaming 'Project'
Posted by Eric Dobbs <er...@dobbse.net>.
In an effort to speed the brainstorming along I thought I
would offer this list of names I've seen and include a
count of the recent "voters". I've added a couple more
suggestions.
Votes New Name Voters:
-------------------------------------------
1 AuthorizationContext Eric
1 Context Scott
1 Domain Gareth
Module
PermissionContext
Project
1 Realm Gareth
1 Resource Jason
1 Scope James
SecurityContext
Zone
I personally think Context has the best fit but is used
EVERYWHERE. Maybe one of the FooContexts would work.
There are precidents: JAAS has a LoginContext there's a
NamingContext in JNDI.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security Changes (3 of 3) - Subject, Principal, Project detai ls
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, February 8, 2002, at 07:14 AM, Weaver, Scott wrote:
> 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>
With Gonzalo's enthusiasm for this example, I am convinced that
our proposals are converging to some common ground.
Scott, here's where I see your example fitting into my proposed
implementation. It's the persistent data structure that is
searched inside this method:
PermissionCollection getPermissions(Subject, Project);
Using the terms from your XML config file:
PermissionCollection getPermissions(Role, Group);
(I should add, I'm not attached to PermissionCollection, just
using this JAAS term for expedience).
And obviously Gonzalo sees this fitting into a notion of Scope
in his proposal.
I think it would be good to see how you've implemented this.
Maybe we can check it into the proposals directory in the
rundata_security_branch so we can have a look. I think it will
help catalyze Gonzalo's and my proposals.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>