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 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 [details] [permissions] [remove] Groups will have [details] [remove] and permissions exactly as above... Oh, there should also be 'add new' buttons (or better links) in all list screens.