Roles, role values, Permission inheritance

[Migrated From Jforum.net]

Hi, me again,

Without having looked at it too hard, I'm confused by the security model

- Why don't child groups seem to have their own permissions?
- Is there anyway to get a users roles to default back to that of their group (I suppose you use group overide, but it leaves all the user role data in the database no?)

Anyway I'm not sure I'm fully understanding the situation.
This is the way I see it:
-I think all permission should inherit from the parent group, if overiding is permitted by that group, for child groups.
-Users need some kind of muliple inheritance for all the groups which they are in (something analogous to a boolean OR, where they get the best set of permissions available to them).

Without suggesting the best way to do this in the database ...

also-
Suggestion: should there be an interface Principal which both user and group inherit from (and means an object which can have roles)?


Mike.

[originally posted on jforum.net by Anonymous]

[Migrated From Jforum.net]

Oops, so you know who I am (thought I was logging in automatically)

Mike.
[originally posted on jforum.net by mgoodwin]

[Migrated From Jforum.net]

mgoodwin wrote:Hi, me again,

Without having looked at it too hard, I'm confused by the security model

Me too

mgoodwin wrote:
- Why don't child groups seem to have their own permissions?

They don't?? hmmm..

mgoodwin wrote:
- Is there anyway to get a users roles to default back to that of their group (I suppose you use group overide, but it leaves all the user role data in the database no?)

You should check "override user values". And, sadly, I think it is not working, anyway.

mgoodwin wrote:
This is the way I see it:
-I think all permission should inherit from the parent group, if overiding is permitted by that group, for child groups.

You're right. I didn't realized on child groups when doing the code.

mgoodwin wrote:
-Users need some kind of muliple inheritance for all the groups which they are in (something analogous to a boolean OR, where they get the best set of permissions available to them).

Users inherits its default permissions from all groups they belong to. At least that's the idea.

I rewrote, rewrote, rewrote and rewrote over and over the security code. I don't know if I was that stupid to can't make a code that works well after so many time, or if is really hard in fact.

I accpet suggestions ( or even contribution with code ).

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Ahh good, we're back online

Hi Rafael,

Well I found what was cauing me trouble. The different mysql drivers are not orthoganal (i.e. you can't change one without changing others) to each other. For instance to change the userstore I've had to overide (still in process of doing) at least the following (in RC3 anyway):

the ForumModel

the PostModel

the TopicModel

the SecurityModel classes

as in each of them some sql references jforum_users/jforum_groups - which i don't want. Of course I can see why they'd do this, with Joins etc, but it does defeat the purpose a bit of having seperate Drivers.

It may be a bit much to have all the sql drivers completely seperate, but (of course this is exactly according to my own requirements) perhaps some logical divisions should be made. i.e. particularly between the Users/Groups and the Forum/Posts/Topics/Categories.

Actually its a miracle I had it working at all (it just so happened that the Admin id was the same in both databases so all the crossreferences didn't break it for that user).

More suggestions coming ...

cheers,
Mike


[originally posted on jforum.net by mgoodwin]

[Migrated From Jforum.net]

Ok, obviously your understanding is going to be deeper than mine, but here are some thoughts:

Scrap RoleCollection/RoleValueCollection (premature optimisation? Wait for generics in jdk1.5)

Denormalize (if you can call it this?) the rolevalues table. I would have one table for 'per table permissions' and one table for 'per user permissions'. I think they are best of handled in seperate tables.

Have a Principal Class (subclassed by User and Group)

Have a 'default to group(s) permission' checkbox in user admin (?) then just display a read only version of permissions.

Hmm, thats all I can think of for the minute,

thanks again,
Mike.
[originally posted on jforum.net by mgoodwin]

[Migrated From Jforum.net]

What's wrong with RoleValue, RoleCollection and RoleValueCollection? I like them .. What's your suggestion?

As I agree that some models are coupled in some weird places, moving the non-model-implementation away will raise a need for refactoring the business logic, which currently is in the ViewHelper. This is not a really easy refactoring task to do right now, in my opinion. At least not before RC4.

I guess you did understand the "generic" model implementation, don't you? I did it that way because, after I'd finished the postgresql implementation, I realized that about 70% of the queries were exactly the same, being insane to maintain it. So, I moved all mysql implementation to the "generic" stuff and just "override" the necessary parts in the pgsql driver.

As I wrote before, the permission control is wrong and really needs a rewrite, but, personally, I don't want to code it right now, since there is other higher priorities on jforum to finish in order to be possible to release 1.0 "soon".

I cannot concentrate more work in the momment, so, if you want to, please be free to make the modifications you want to do, even if it means the complete rewrite of the permission schema.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael Steil wrote:What's wrong with RoleValue, RoleCollection and RoleValueCollection? I like them .. What's your suggestion?

Just normal java.util collections. Its just i remember doing this once to avoid casting, unless there is another reason I'm not sure its worth it.

Rafael Steil wrote:As I agree that some models are coupled in some weird places, moving the non-model-implementation away will raise a need for refactoring the business logic, which currently is in the ViewHelper. This is not a really easy refactoring task to do right now, in my opinion. At least not before RC4.

Ok, cos I think i've got the User interface more or less seperate now, just by changing the sql. Obviously no real urgency was saying how I felt it could be improved (although potentially dividing them all up could slow down performance a bit on the downside, though it probably would be negligible)

Rafael Steil wrote:I guess you did understand the "generic" model implementation, don't you? I did it that way because, after I'd finished the postgresql implementation, I realized that about 70% of the queries were exactly the same, being insane to maintain it. So, I moved all mysql implementation to the "generic" stuff and just "override" the necessary parts in the pgsql driver.

Nope not seen that, I was working off the RC3 source, so I guess some of my comments may have been outdated. I'll maybe have a look at the cvs version tomorrow then.

Rafael Steil wrote:As I wrote before, the permission control is wrong and really needs a rewrite, but, personally, I don't want to code it right now, since there is other higher priorities on jforum to finish in order to be possible to release 1.0 "soon".

Don't get me wrong, it does work, i think its probably the hardest bit to get right. I'm sure you will.

Rafael Steil wrote:I cannot concentrate more work in the momment, so, if you want to, please be free to make the modifications you want to do, even if it means the complete rewrite of the permission schema.

Nope, I don't mind. If I can have a positive input then that would be great. Oops, gotta go now, later, thanks,

Mike.
[originally posted on jforum.net by Anonymous]