proposals/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...