You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by jv...@apache.org on 2001/09/02 08:40:21 UTC
cvs commit: jakarta-turbine-flux/xdocs admin-app security-chat
jvanzyl 01/09/01 23:40:21
Added: xdocs admin-app security-chat
Log:
- moving security app notes into the flux repository
Revision Changes Path
1.1 jakarta-turbine-flux/xdocs/admin-app
Index: admin-app
===================================================================
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 <Ra...@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.
1.1 jakarta-turbine-flux/xdocs/security-chat
Index: security-chat
===================================================================
<jason> basically, there is no way to associate a role with a group.
<jason> if i wanted to display a list of roles for a project, you can't do it right now.
<jason> there is no table that binds roles with groups.
<jason> but the grant(User, Group, Role) requires all three.
<jason> there is no TURBINE_GROUP_ROLE, so there is no way to add a role to a project.
<jason> so there is no way to display a list of roles for a project.
<jason> am i missing something?
<jason> i asked daveb to look at it and he arrived at the same conclusion i did.
<fedor> the point is that roles are global
<fedor> so there is no and should not be an assoc between them
<fedor> again: roles do not belong to projects
<fedor> if the did
<fedor> you whould not need a Group as parameter to grant()
<fedor> it would be implied
<fedor> example:
<fedor> there is role "admin"
<fedor> which has certain permissions (does not matter)
<jason> the javadocs _say_ role _within_ a group.
<fedor> it says:
<fedor> .. assign user a role within a group...
<fedor> you should read:
<fedor> assign... within a group
<fedor> not
<fedor> role within a group
<jason> well that's not what it says.
<fedor> no!
<fedor> it's a grammatical ambiguity
<jason> and if roles are global then why is there a group table?
<fedor> "within" attaches to "assign"
<jason> if there is only one.
<fedor> sounds like we are where we've started...
<jason> in our discussion of how you thought the projects should be display with all the roles associated with that project: i can't do that.
<fedor> group is NOT a group of roles!
<fedor> there are no roles assoc with a project
<fedor> let's go back to the example, OK?
<fedor> we have few roles (they are global):
<jason> hold on one sec.
<fedor> "admin", "developer", "tester", "guest"
<fedor> go ahead
<jason> but what if you wanted an admin role for each project, why is there even a group table if all roles are global?
<jason> this is really pissing me off.
<jason> the docs suck!
<fedor> group is a project
<jason> yes, i get that [ even though the names are god awful ]
<jason> but you also said that permission are global, but there is a table relating permissions with roles?
<fedor> role IS a group of permissions
<jason> i am just trying to produce the first form that we discussed. can we do that?
<fedor> produce what?
<fedor> go ahead
<jason> i thought we were going to present the admin with a list of projects and the roles associated with those projects and the intersection would be checkboxes.
<jason> you sure there isn't a mistake in the schema and the rafal just used the global group for everything?
<fedor> omit "associated with those projects" and i agree
<jason> so you just show a huge list of roles that are global?
<fedor> right
<fedor> not amny though
<fedor> s/amny/many
<fedor> not so many.
<jason> well, for tambora we have different groups/projects and the roles for those projects are distinct so if this thing works with only global roles then i think there's a problem.
<jason> how can projects share the same set of roles.
<fedor> can you tell what particular roles those are?
<fedor> i want to see why you need that
<fedor> and persuade you that you do not ;-)
<jason> in tambora there are two distinct systems, storage and transport and the roles within them are very different.
<fedor> can you elaborate more?
<jason> can we go over an example of how you think it works. the last time we were discussing this with john, i got the distinct impression that roles were separated by group. we were arguing whether to use checkboxes or lists because you might have to select a project before selecting a role.
<fedor> ;-)
<fedor> ok i continue:
<fedor> fedor> we have few roles (they are global):
<fedor> <fedor> "admin", "developer", "tester", "guest"
<fedor> ("fedor" is not a role ;-)
<jason> :-)
<fedor> and we have a few projects:
<fedor> "scarab", "turbine", "velocity"
<fedor> and there are users:
<fedor> jon, geir, jason
<fedor> you do:
<fedor> grant(jon, scarab, admin);
<fedor> grant(jon,scarab,developer)
<jason> that sucks!
<fedor> grant(jason, scarab, developer)
<fedor> why?
<fedor> it's normal
<jason> "tester"
<jason> what if in turbine you wanted "pool-connection-tester"
<fedor> what's the point?
<fedor> you create subproject
<jason> that doesn't apply to the other projects, you're stuck with totally general categories.
<fedor> in turbine called "pool-connection"
<fedor> and give that user "tester" in it
<fedor> Give another example where you need it
<jason> but turbine is the top-level project?
<fedor> probably
<fedor> what's the diff?
<jason> you are telling me that roles will never vary for each individual project?
<fedor> roles are the same
<fedor> but set of roles
<fedor> assigned to a user is individual
<fedor> in our last example
<fedor> user "ThatGuyThatTestsPoolsAndNothingElse"
<fedor> will have "tester" role in "connection-pool" subproject
<fedor> and "guest" role in project "Turbine"
<jason> but the name tester will be duplicated then "tester" for turbine, and "tester" for the connection pool on the list of roles?
<jason> what if you had turbine as the tool for a website management tool: you would have content managers, editors, designers. you are telling me that the roles each of these people play would be the same?
<jason> no way.
<fedor> if they perform different _functions_
<jason> say the designer was could change some ui features, the content providers (sorry not content manager) could enter articles, and the editors had approval abilities.
<fedor> those whould be different roles
<jason> but they are roles of those distinct categories!!
<fedor> those are different roles
<jason> yes!
<jason> but there would be roles associated with a designer that bear no relation to the roles of a content manager.
<fedor> what categories are you talking about?
<jason> designer/content provider/editor
<jason> you are saying those are roles?
<fedor> those are roles
<fedor> and say you have a site hosting...
<jason> i think i'm one level away ...
<fedor> a few "web portals" or somethin
<fedor> what's the project(group) breakdown you would have?
<jason> each site would probably be a project.
<fedor> right
<jason> but one site might deal with mutual funds and one with books.
<fedor> and each would have "designer/content provider/editor"
<fedor> but roles as far as site management is concerned are the same
<jason> sure, but you can't get any more specialized then that?
<fedor> example!
<jason> say you have a mutual fund analyst role, and they can do certains things on the mutual fund site that wouldn't happen on the book site.
<fedor> isn't he just a content provider?
<jason> yes, but that's a little general.
<jason> for a huge financial portal you would probably have distinct financial type roles.
<jason> for a huge literary site you might want to break up what types of content they provide.
<fedor> are we talking about a site management
<fedor> or
<jason> yes, site management
<fedor> financial analysis tool
<fedor> you are mixing the two i think
<fedor> these would be two different pieces of software
<jason> no. ok say we just have content provider.
<jason> as the one role of someone who can add content to the site.
<fedor> ana each would have it's own set of roles
<fedor> go
<jason> a set of roles only applies to a user, yes?
<jason> jason is content provider, editor
<jason> s/is/is a/
<fedor> or rather :
<fedor> .. is a CP in project A, editor in project B
--> Rafal (-fil@gw.e-point.pl) has joined #turbine
<Rafal> hi
<fedor> hi
<jason> hi rafal
<fedor> you are just on time!
<jason> so what we are saying is that roles are universal across all projects?
<jason> that one sentence would clear a lot up for me.
<Rafal> yes. roles should be abstract
<Rafal> I see you wrote a proposal for the admin app
<Rafal> I'll read it in a minute
<jason> yes, i think i have a fundamental misunderstanding that fedor just cleared up.
<Rafal> we discussed the role/group stuff with Fedor and Jon a while ago
<jason> i did not think of roles as universal, but being held within a group/project.
<jason> yes, but the logs aren't kept anywhere, and i couldn't anything useful in the mail archive, mostly because the search facility sucks. but fedor has been trying to educate me.
<Rafal> no... roles are universal, but you assign them to an user *within* a group (project etc)
<jason> yes, that has finally sunk in.
<jason> that is the one sentence i was looking for "roles are universal".
<jason> ok, we were talking about a portal site can we just go a little further with it?
<jason> we had the roles of designer/content provider/editor
<Rafal> sure
<jason> and we had two sites, a large financial site, and a large literary site.
<Rafal> I have working portal software running on Turbine
<Rafal> so I know this sort of stuff
<jason> great!
<Rafal> in our system we have a content tree
<Rafal> each of the portals would be children of the root node
<jason> and do you distinguish who is actually allowed to add/edit particuluar types of content?
<Rafal> in our system we associate a turbine group with a node (and possibly it's children)
<Rafal> then we have roles a few 'editor' roles with varying set of permissions
<Rafal> (like edit article, add section and so on)
<jason> so each group is a different site?
<Rafal> yes. you can have a few groups for one site - for particular parts of it.
<Rafal> a fragment of the content tree...
<Rafal> it's clean and simpe
<jason> can continue with my example, and then you point me in the right direction vis-a-vis making new groups/perms and what not?
<Rafal> what do you think?
<Rafal> ok. you have some abstract contnent tree
<Rafal> you establish a mapping between the contnent tree and turbine groups
<Rafal> for an arbitrary content node, you can give a list of one or more turbine groups that are asociated with it
<Rafal> you create a role 'contnent provider' and 'editor' roles
<Rafal> define permissions 'add article' 'edit article' 'remove article' 'add section' 'remove section'
<Rafal> 'content provider' has article related permissions, 'editor' has both article and section related.
<jason> so for distinct parts of your site you have created turbine groups. ok that helps a lot too.
<Rafal> then assing 'content provider' in 'portal A' group to 'John Doe' user, and so on.
<jason> and so the 'content provider' role in group A can have a different set of permissions then the role 'content provider' in group B?
<Rafal> the administrative application has to check what groups the 'current node' is associated with
<Rafal> and check if the user has the permission to execute an action whithn any of these groups.
<Rafal> the 'groups' abstraction that Jon forged for Scarab project proved to be really useful...
<Rafal> no. a role has a single set of permissions.
<Rafal> if you need a different set, you can create a different role, but ...
<Rafal> in this portal related stuff here, the permissions should be basicly the same in all parts of the portal.
<Rafal> so should be the roles.
<Rafal> user 'A' can be content provider for the financial site, and an editor of some part of the other site...
<jason> how about the notion of a content provider for a financial site being different from that of a content provider for a literary site: say for a financial CP permission to change daily stock quotes, and literary CP say update top 10 list?
<Rafal> no, these are different roles
<Rafal> why would you like make them one?
<jason> so then 'financial content provider' and 'literary content provider'?
<jason> i'm simply trying to understand the model, that's all.
<jason> and each of those roles have their own perms. ok.
<Rafal> yes
<fedor> i think content provider is content provider that's it
<Rafal> if the 'content' means the same in both sites, you need one role
<Rafal> usually the portal will have both 'articles' and 'applications' embeded in the application tree.
<Rafal> usually applications will need different roles/permission than the articles.
<Rafal> s/application tree/navigation tree/
<jason> thanks, rafal that helps a lot!
<Rafal> ok
<jason> ignore my postings, as i had a fundamental misunderstanding.
<Rafal> allright :)
<jason> i will adjust the proposal as i understand now how it's supposed to work.
<jason> do you use a webapp for your admin, or using an LDAP client?
<Rafal> talking about the proposal, AccessControlList is not pluggable
<Rafal> AccessControlBuilder is not used any more (access.control setting in TR.p)
<Rafal> we use database console right now :(
<jason> ah!
<Rafal> we don't have too many adminstrators in our portal so it kind of works...
<jason> yup, i do that too.
<jason> ok, so the access.control is a property that can be removed now?
<jason> i will clean that up if that's the case.
<jason> can i remove the whole access control section from the TR.props.
<Rafal> i'm lookin at the master file right now and it's not there
<Rafal> hmmm I must have removed it earlier.
<jason> ok, i'm looking at project i'm working on and it's probably not updated.
<jason> so people never have to extend the AccessControlList class?
<Rafal> no. there's no way to do this now, and I think there is no need to.
<jason> that's cool. just checking. i will write an xdoc today. with the info i've gathered here and finish the proposal so i can get started on the admin app for tambora and the tdk.
<Rafal> good.
<Rafal> my friends have some ideas for the UI...
<Rafal> I need to write the down.
<Rafal> OneWeb (the other e-point project) has quite nice security admin app and we could steal a few bits
<jason> cool, just toss them in the proposals directory and we can work on them together.
<jason> sure that would be great! i have to get something working this week for tambora.
<Rafal> I'll be back in a minute...
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org