Ben Alex wrote:
administrator wrote:
Thanks Ben,
What I'm trying to do on a functional level is quite straightforward.
The application that I am writing is intended for the real estate
business.
In this business a sales agent will only be able to view/edit properties
that he/she has been assigned/brought into the company.
So when for example an agent does a search for houses they should
only be returned those that they are in charge off.
Hi Bryan
The way I'd approach this is to use as much Acegi Security
infrastructure as possible. Whilst you could use your own SystemUser
object etc, unless there is a compelling value-add you will have to
maintain it when there is likely an already functional alternative
maintained as part of Acegi Security. Specifically, the UserDetails
interface and the User implementation of same can store your
authenticated user information. This will be available from the
((SecureContext) ContextHolder.getContext()).getAuthentication(). Is
there any particular reason you wouldn't want to use these classes?
------------------------------------------------------------------------------------------------------------------
Yes the reason is that for database performance reasons it makes sense
to asign an auto-incremented key
to each user. This makes lookup,joins and updates a lot faster and also
provides an easy way to run such
things as "get the last 20 users who joined up".
Also I don't know how familiar people on the list are with the hibernate
data model but just for a little
bit of background.
( THIS IS ALL PSEUDO CODE )
SalesPerson extends SystemUser.
SalesPerson -> id = 1
SalesPerson ->username = "ted"
SalesPerson ->branchId = 2
SalesPerson ->Properties = Set ( Property-> id = 1; Property-> id = 4
etc etc )
Property -> id = 1
Property->branchId = 1
Property -> name = "big house"
Property -->salesPersons = Set ( SalesPerson -->id = 1; SalesPerson
-->id = 2 etc etc )
Using hibernate it is possible to do the following ( pseudo code )
SalesPerson salesPerson = hibernate.find( "SalesPerson as salesperson
where salesperson.id = 1");
Set properties = salesPerson.getProperties();
etc etc
Also you can do this
Integer branchId = salesPerson.getBranchId();
Properties props = hibernate.find( "Properties as properties where
properties.branchId = ?", branchId);
This will not return the Property that I created earlier because it's
branchId = 2 and the salesperson has
a branchId of 1
So you can see how it would be a lot easier to implement fine grained
security if I had access to the Users
numeric id.
----------------------------------------------------------------------------------------------------------
You see the thing is that I am developing this as an open source
application.
I was enormously impressed by your contacts demo application and the way
that it made exposing the
service layer so easy.
However it is a little cumbersome to have to do this
snip=
public class ContactManagerFacade implements ContactManager,
InitializingBean {
//~ Instance fields
========================================================
private ContactManager backend;
//~ Methods
================================================================
/**
* Security system will ensure the owner parameter equals the currently
* logged in user.
*
* @param owner DOCUMENT ME!
*
* @return DOCUMENT ME!
*/
public Contact[] getAllByOwner(String owner) {
return backend.getAllByOwner(owner);
}
=snip
If I can do what I am trying to do this method signature could be
changed to the following.
public Contact[] getAllByOwner(String owner) {
public Contact[] getAllMyContacts() {
Integer userId = this.user.userId(); // The current user from the
secure session ???
//Some hibernate stuff goes here.
}
Now I can expose this exact same service facade to
hessian,burlap,httpinvoker or Struts with
no additional logic.
This means that I can provide the interfaces to people who might be
interested in developing
a desktop client application for my system .
They dont need to know anything about security , all that they have to
do is create a hessian
session, connect to the server with a username/password combination and
take it from there.
I really think that hibernate / ejb3 is what everyone is going to be
using very shortly so I would
love to be the one to get this working and have a really s&$! hot
example app that people could
use to stick it to the .Net guys.
--b
PS: I hope I amn't being too much of a pain in the ass but I think this
could be really cool. I'm
thinking that this could be the equivalent of Sun/Linux pam
authentication system ( which rules ).
As for the access control list (ACL) part, you'd use the new
net.sf.acegisecurity.acl.basic package. This is discussed in the 0.6
reference manual, although there still isn't a sample application.
Essentially you'd use the JdbcDaoImpl which retrieves ACLs from a JDBC
backend. You'd then use the AclProviderManager as your AclManager
implementation, which is wired to a BasicAclProvider, and in turn that
is wired to the JdbcDaoImpl. You'd then write a custom
AccessDecisionVoter which has a reference to the AclManager bean. The
AccessDecisionVoter would check with the AclManager to ensure the
Authentication object has access to the presented real estate
property. If access is denied, the AccessDecisionVoter would throw an
AccessDeniedException. That's all fine for working with specific real
estate properties, but in terms of getting a list of real estate
properties that users have access to, you would probably be best to
write a MethodInterceptor which inspects a returned List and mutates
it to remove real estate properties to which the user has no access.
Thus it could be used with any of your finders, as it is a
cross-cutting concern.
As above , all this would be simpler if the service bean had access to
the users numeric id.
In relation to the Hibernate filters, yes, it seems like they would
work if each real estate property could only have a single
salesperson. But for the sake of spending a little time writing the
MethodInterceptor and setting up the ACL package, you'd have much more
flexibility (eg >1 salesperson per property, hierarchy perhaps based
on locations of the real estate properties, hierarchy perhaps based on
internal sales teams, allowing clients to edit their property details
over the web, permitting limited access to certain real estate
properties by other team members and so on).
This is all handled by the existing Hibernate data model.
Best regards
Ben
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
