Work in progress

This proposal outlines an implementation for a standard
Turbine admin app that could easily be extended so that
there would be a usable base for an admin app for all
Turbine applications.

--------------------------------------------------------------------------
N O T E S
--------------------------------------------------------------------------

The Security Service manages Users, Groups Roles and Permissions
in the system.
 
The task performed by the security service include creation and removal of 
accounts, groups, roles, and permissions; assigning users roles in groups; 
assigning roles specific permissions and construction of objects 
representing these logical entities.

Because of pluggable nature of the Services, it is possible to create 
multiple implementations of SecurityService, for example employing database 
and directory server as the data backend.

The SecurityService delegates to the specified pluggable components.
The pluggable components include User and UserManager implementations. 
These classes are specified in the TR.props.

services.TurbineSecurityService.user.class
services.TurbineSecurityService.user.manager

Do not use user.setPassword(password), use the following method
to add a user: TurbineSecurity.addUser(user, password)

--------------------------------------------------------------------------
U S E R  A D M I N  F O R M
--------------------------------------------------------------------------

This will be the form used to insert/update/delete user accounts
in the Turbine application.

Fields:

USERNAME
FIRST_NAME
LAST_NAME
EMAIL

NOTE:

Roles are universal, Roles are global and apply to all Groups.
A Group is not a Group of Roles! A Group is not a Group of Users either!
A Group is more akin to a project.

A Role is a single set of permissions.

Each Group will be displayed with the same set of Roles beneath
it in a selector box. We'll use Scarab as an example here.

In Scarab we may have the following Groups (or projects):

Turbine, Velocity, and ECS

We may have the following Roles:

Admin, Developer, Tester, and Guest

So what we would display for each Group is a list
of the Roles in a multi-select SelectorBox. So it might look
something like the following:

Turbine    Velocity    ECS
-------    --------    ---
Admin      Admin       Admin
Developer  Developer   Developer
Tester     Tester      Tester
Guest      Guest       Guest

So you may choose to assign Jon the role of Admin for Turbine,
and assign Jason the role of Developer in Velocity.

You would then use the following method to have these choices
take affect:

TurbineSecurity.grant(Jon, Turbine, Admin)
TurbineSecurity.grant(Jason, Velocity, Developer)

--------------------------------------------------------------------------
P R O J E C T / G R O U P  A D M I N  F O R M
--------------------------------------------------------------------------

This will be the form used to insert/update/delete projects/groups
in the Turbine application.

Fields:

GROUP_NAME

--------------------------------------------------------------------------
R O L E  A D M I N  F O R M
--------------------------------------------------------------------------

This will be the form used to insert/update/delete roles in
a project/group in a Turbine application.

!!
Is this form even intended because I don't see any way to save
the association between a role and a group currently.

Fields:

GROUP/PROJECT ID (I thought that roles were associated with projects/groups)
ROLE_NAME

--------------------------------------------------------------------------
P E R M I S S I O N   A D M I N  F O R M
--------------------------------------------------------------------------

This will be the form used to insert/update/delete permission in
a Turbine application. Fedor mentioned that permissions were
global. I'm not exactly sure how that works right now.

Fields:

?

--------------------------------------------------------------------------
E X T E N D I N G  T H E  A D M I N  A P P
--------------------------------------------------------------------------

Is there any easy way to allow Torque to generate the peers used
by the security system. This way if any changes were required to
the user class then it would be a matter of changing the XML schema.

Now these are special peers with convenience methods, and methods
specific to security. But a special set of templates could probably
be made to accomodate this.

Just trying to think of the best way to make a security app
resuable WRT any customizations that might want to be made
to the user schema.

In most cases would it simply be the user schema that
will want to be changed?

Is there already a recommended way to extend the existing
classes to make a different security system and accompanying
admin app?

---

These are notes from Rafal that I will integrate

From Rafal.Krzewski@e-point.pl Tue Jan  2 13:32:59 2001
Date: Tue, 02 Jan 2001 20:08:45 +0100
From: Rafal Krzewski <Rafal.Krzewski@e-point.pl>
To: jvanzyl@periapt.com
Subject: admin app

    [ The following text is in the "iso-8859-2" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

user list has filtering control on top of the page.
You can chose login/first name/last name, etc and the pattern
(* will be changed into % before going into the LIKE query)

the links on the right should be:

'edit' or 'details' - takes you to the edit user screen
'roles' - take you to user-group-role edit screen
'remove' - ask for confirmation, and...

the second screenshot shows user-group association from OW
which would be user-group-role in Turbine.

we need a pulldown list for selecting a group at the to.
it should have 'global' group preselected.

The role-permission screen should look in a similar way.

Roles screen will be like users, it will have

<role name> [details] [permissions] [remove]

Groups will have

<group name> [details] [remove]

and permissions exactly as above...

Oh, there should also be 'add new' buttons (or better links)
in all list screens.