Security framework (not only a pull tool), Part 1

[Jacopo Cappellato <ja...@libero.it>]

Hi,

as probably someone in this list already knows (see the threads "Security
framework for modules" and "Best way to use groups, roles, permissions..."),
I'm studing a good approach to deal with security in Turbine applications.
After several hours spent thinking about this subject and thanks to the
valuable advices of Scott Weaver and Leandro Rodrigo, I managed to develop a
IMHO very flexible and easy to use security framework.
Its main components are:
1) a pull tool
2) some action and screen classes that can be extended, that help to
traparently use the tool
3) a security conf file to be imported into (or appended to) the
TR.properties file

The framework's description is quite long and so I will split it into two
parts (two messages): in this first part I'm going to describe the global
architecture, while in the second I'm going to show you the details (and the
code).

At now, I'm testing the framework, and I'm satisfied of it... but I think
that this is only a starting point:
I hope to receive your feedback and so... if someone is interested, PLEASE,
ASK ME the code, HAVE a look at it (ASAP I will put it into my homepage),
TRY it...

Jacopo

PART 1 - MAIN CONCEPTS

If we use the security framework in a Turbine application we can find that
three persons will interact with it during development and deployment: a
DEVELOPER, a TEMPLATE DESIGNER and the DEPLOYER.

The DEVELOPER, the one that creates the modules (mainly screen and action
classes), has the following responsibilities:
a) he assigns a security label (name) to the module (modules with the same
name, e.g. a default name, share the same security config parameters): we
could think of it as a family name
b) he decides which tasks, within each module, need to be secured; a TASK
could be for example "DISPLAY_PRICE" (all users could see a screen but only
trusted ones could see the items' prices in it); a very common task is
"ACCESS": the access to the screen needs to be locked against untrusted
users (the same control made by isAuthorized(..) method in
VelocitySecureScreen).
An important point to note here is that the developer DOESN'T say nothing
about the level of security needed to execute a task: he totally ignore all
the security stuff: which groups are defined whithin the system, which roles
and permissions and so on. He only says: "OK, this task (e.g. the
DISPLAY_PRICE task) needs a security check!".

The TEMPLATE (Velocity) DESIGNER has the following responsibility:
a) due to security constraints, some users could see different things in the
page... he has to know what could change and, accordingly to this, design
the template correctly.

The DEPLOYER is the one responsible for the configuration, at deploy time,
of all the module security, in details:
a) he creates (e.g. using Flux) all the groups, roles, permissions and users
that he wants
b) he configures (by editing the TR file) the level of security necessary to
perform each task of each module family (as defined by the DEVELOPER): he
can also define a DEFAULT module security





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

Re: Security framework (not only a pull tool), Part 1

[Jacopo Cappellato <ja...@libero.it>]

Hi Dave,

hmmm... you are right... sorry for my bad English and thank you for your
comment.

Regards,
Jacopo

----- Original Message -----
From: David Warnock <da...@sundayta.com>
To: <tu...@jakarta.apache.org>
Sent: Wednesday, October 24, 2001 12:44 AM
Subject: Re: Security framework (not only a pull tool), Part 1


> Jacopo,
>
> I am not qualified to comment much on the technical aspects of turbine
> although what you are saying does sound very sensible to me.
>
> Just one immediate comment.
>
> > An important point to note here is that the developer DOESN'T say
nothing
> > about the level of security needed to execute a task: he totally ignore
all
> > the security stuff: which groups are defined whithin the system, which
roles
> > and permissions and so on. He only says: "OK, this task (e.g. the
> > DISPLAY_PRICE task) needs a security check!".
>
> One change which corrects the meaning to what you seem to want.
>
> In the first line "nothing" should be "anything".
>
> If I was being really pedantic then "ignore" should be "ignores".
>
> But I am not complaining, I like what you are proposing, it does sound
> like it would clearly be very useful.
>
> Regards
>
> Dave
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

Re: Security framework (not only a pull tool), Part 1

[David Warnock <da...@sundayta.com>]

Jacopo,

I am not qualified to comment much on the technical aspects of turbine 
although what you are saying does sound very sensible to me.

Just one immediate comment.

> An important point to note here is that the developer DOESN'T say nothing
> about the level of security needed to execute a task: he totally ignore all
> the security stuff: which groups are defined whithin the system, which roles
> and permissions and so on. He only says: "OK, this task (e.g. the
> DISPLAY_PRICE task) needs a security check!".

One change which corrects the meaning to what you seem to want.

In the first line "nothing" should be "anything".

If I was being really pedantic then "ignore" should be "ignores".

But I am not complaining, I like what you are proposing, it does sound 
like it would clearly be very useful.

Regards

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

Re: Security framework (not only a pull tool), Part 1

[Bernard Bielinski <B....@pap.com.pl>]

Suppose we have 2 separate (different) services ( written in Turbine of course ) on 2 komputers using one database.
Assume we need one authorisation what is valid on both of them in one session time. I mean there is only one template 'Login.vm'.

What should be done to create such onified authorisation? (That is your suggestion in this situation?)

Greetings
Bernard Bielinski


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

Re: Security framework (not only a pull tool), Part 1

[Daniel Rall <dl...@finemaltcoding.com>]

"Age Mooy" <am...@home.nl> writes:

>> The DEPLOYER is the one responsible for the configuration, at deploy time,
>> of all the module security, in details:
>> a) he creates (e.g. using Flux) all the groups, roles, permissions and users
>> that he wants
>> b) he configures (by editing the TR file) the level of security necessary to
>> perform each task of each module family (as defined by the DEVELOPER): he
>> can also define a DEFAULT module security
>
> Is there any reason why step b) can't be integrated into Flux ? Maintaining security in two different places
> doesn't seem an ideal solution to me.

If I understand correctly (and I'm not certain that I do), they're
already in Flux via its User-Role-Group security model.

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

RE: Security framework (not only a pull tool), Part 1

[Age Mooy <am...@home.nl>]

> The DEPLOYER is the one responsible for the configuration, at deploy time,
> of all the module security, in details:
> a) he creates (e.g. using Flux) all the groups, roles, permissions and users
> that he wants
> b) he configures (by editing the TR file) the level of security necessary to
> perform each task of each module family (as defined by the DEVELOPER): he
> can also define a DEFAULT module security

Is there any reason why step b) can't be integrated into Flux ? Maintaining security in two different places
doesn't seem an ideal solution to me.

Age



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org