Design question - Spring service with different user groups

[Pieper]

Hi,

I have a design question about my webapp.

There are different user groups (admin, user, guest). Now I want to separate the access to the service, depending of the user, who accesses the class via the Wrapper class.

Common architecture is:

Presentation_________________Apache Cocoon
Controller___________________Apache Cocoon
________ ------ Wrapper class -------__________
Main Spring Service Interface___MainService
Main Spring Service Interface___MainService Impl
*****
UserService, GuestService, AdminService
*****
--------- DAO interfaces ---------
--------- HibernateDAO ----------
--------- database (mysql) ------

The question now is, how to differ between the different service classes. The administrator can use all services, the user can use the services for user and guest and the guest user can only use the guest services.

So, to have a OOP design, I want to have a common class, which has the services, which all user groups can access, and the user group services inherit from this common class.

As I access the main Spring service class via the beanfactory, the question is, if I should access the user group classes also via the beanfactory and interfaces or is there a other possiblity to do this?
(in the architecture the part with the stars - the interface - is the main part, I'm not quite sure)

A other design would be to have all the methods in the main service class, but then I have a service class with nearly 25 methods. I don't think, that this is a good approach.

Looking forward to your suggestions.

Thanks in advance!

ciao,
Pieper

[moo]

ok, i'll try to :)

i see two difficulties... the one you already described and the other related to objects created by your users.

1. leave everything in one class (bean :) ) but use delagation, if you like to factor out functionality into other beans and expose your services via service interfaces (yes facade pattern again). i.e that will give you IAdminService, IUserService, IGuestService interface... This could be automagically wired together with Spring.

2. What about objects created bys users? Take the posting you are reading now and just decide who else is allowed to read it.

Rule: Objects should be "accessAware".
Ok, think of the unix filesystem but replace "file" by "object" :)
According to an object the world is devided into three groups: Owner, Groupmember, Others.
and every object knows of the operations it is allowed to expose to others.
Operations are create, retrieve, update, delete (CRUD).

Example?

This board's "posting" object allows

me the owner to CRU

registered users to CR ( C includes answering my posting = creating a new one)

not registered users only to R

And by default the super user (administrator) is allowed to CRUD.

So, when you create a service think of the objects involved and define their access behaviour.

That's it.

Mo

[Ben Alex]

I didn't really fully understand your post, but Acegi Security can provide role-based access control as well as access control lists. The former is ROLE_ADMIN, ROLE_USER being applied against URIs and method invocation patterns. The latter is the create, read, write, update, delete, (custom etc) permissions assigned against domain object instances (eg like the forum example discussed).

If you used Acegi Security you could write separate beans for each class of user, or put all the methods into one service class. It really doesn't matter from a security point of view - it should be primarily decided by OOP design effectiveness.

[moo]

I didn't really fully understand your post


I didn't know that Acegi Security implements UNIX style ACL, sorry about that.

[Pieper]

If you used Acegi Security you could write separate beans for each class of user, or put all the methods into one service class. It really doesn't matter from a security point of view - it should be primarily decided by OOP design effectiveness.

Thanks for your posting.

My main concern is not a security issue, but a good OOP design. ;-)

Will take a look at Acegi Security. But I think, if I add a new component to the system, it will be to complex. How is the learning curve of Acegi Security ?

Pieper

[Pieper]

ok, i'll try to :)

i see two difficulties... the one you already described and the other related to objects created by your users.

1. leave everything in one class (bean :) ) but use delagation, if you like to factor out functionality into other beans and expose your services via service interfaces (yes facade pattern again). i.e that will give you IAdminService, IUserService, IGuestService interface... This could be automagically wired together with Spring.


I think this is a good approach, I should take a deeper look into.

How should this "automagically wired" work? Should I use a BeanFactory to access the interfaces? The DAOs would be wired to each service implementation, wouldn't it?


2. What about objects created bys users? Take the posting you are reading now and just decide who else is allowed to read it.


What's the problem with objects created by users? It's the same as objects created by admins, isn't it?


Rule: Objects should be "accessAware".
Ok, think of the unix filesystem but replace "file" by "object" :)
According to an object the world is devided into three groups: Owner, Groupmember, Others.
and every object knows of the operations it is allowed to expose to others.
Operations are create, retrieve, update, delete (CRUD).

Example?

This board's "posting" object allows

me the owner to CRU

registered users to CR ( C includes answering my posting = creating a new one)

not registered users only to R

And by default the super user (administrator) is allowed to CRUD.


Thanks for the example.


So, when you create a service think of the objects involved and define their access behaviour.


Ok, and the access behaviour should be done like you described in (1.)



That's it.
Mo

Thanks! :-)
Pieper

[moo]

this is slowly getting OT I think... anyway
1a. study Template Pattern (gof)
1b. let DI inject the template class
1c. Template class could be AbstractUserService
1d. AbstractUserService controls a bunch of service methods (i.e. createUser)
1e. Use Spring DI to inject the concrete implementation of service methods into AbstractUserService
1f. AbstractUserService implements IUserService exposing only a subset of IService
1g. Of course you have to extend AbstractUserService


Ok, and the access behaviour should be done like you described in (1.)



2a. Access behaviour means "ACL". It is an integral part of your objects. see Acegi docs to learn about ACL.
2b. You would be well advised if you externalized ACL infomation (see Acegi).
2c. Leaving ACL in your objects allows more fine grained access policy
2d. Sometimes this policy is very fined graind and reflecting all sorts of permissions through service interface becomes impossible.

3. Everytime you want to instantiate an object (appart from new
String() :) ) within a class think about DI

4. Follow your inspiration, use TDD and things will get clearer.

Mo