Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
Guys, I'm going to leave this topic, go off and start coding some of your suggestions. Thanks for all your assistance and I'll let you know if it all works out well. --b On Tue, 17 Aug 2004 17:46:58 -0700, March, Andres [EMAIL PROTECTED] wrote: I agree. We have easily extended the ACL classes at logical points to handle our business particulars. The db schema was the first such issue. From what I have read on this thread, your use cases are pretty simple and you just need to learn more about how to extend acegi at the right places. The docs are pretty good for any software but the test cases are great. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Tuesday, August 17, 2004 5:35 PM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah ) Oliver Hutchison wrote: Using hibernate it is possible to do the following ( pseudo code ) SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.id = 1); Why not just use the username (which should be unique) to lookup the SalesPerson? SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.username = ?, user.getUsername()); Assuming there's and index on username performance would not be an issue. Ollie Hi Bryan I am inclined to agree with Ollie. Your other requirement (the last 20 users who signed up) could be equally as effectively addressed by an additional indexed column, createdDate. Acegi Security has no problems with you adding additional columns to the schema (or backend) managed by an AuthenticationDao. You can even return such additional details in the UserDetails implementation returned by the AuthenticationDao. I do not believe any of your use cases could not be effectively and modularly accommodated using the existing Acegi Security packages. Its usefulness for your authentication needs is beyond a doubt. The ACL side is a little grayer, simply because the ACL packages are quite new. Having said that, I am fairly confident they'd meet your needs as described in my earlier email. The ACL packages are reasonably flexible if you really wanted to completely re-engineer the schema: check the list archives for a recent discussion between Andres March and myself about this. In relation to remoting integration, as you may have noticed in the Contacts sample application, Acegi Security provides support for this via its BASIC authentication filter. In addition, there is a new RCP package which can be helpful for ensuring a valid login request has happened at the client end. Check out the Petclinic RCP sample (part of the spring-rcp project) to see this in use. I'd suggest trying to integrate authentication without worrying about the ACL side. Then, once you see that working, review how the included ACL packages work. It will be a lot clearer when you understand the place where the method security interceptors, ContextHolder, AuthenticationDao, and AccessDecisionVoters fit into the bigger picture. Of course we're also happy to continue helping you on-list. 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 --- 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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
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
RE: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
Using hibernate it is possible to do the following ( pseudo code ) SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.id = 1); Why not just use the username (which should be unique) to lookup the SalesPerson? SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.username = ?, user.getUsername()); Assuming there's and index on username performance would not be an issue. Ollie --- 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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
Oliver Hutchison wrote: Using hibernate it is possible to do the following ( pseudo code ) SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.id = 1); Why not just use the username (which should be unique) to lookup the SalesPerson? SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.username = ?, user.getUsername()); Assuming there's and index on username performance would not be an issue. Ollie Hi Bryan I am inclined to agree with Ollie. Your other requirement (the last 20 users who signed up) could be equally as effectively addressed by an additional indexed column, createdDate. Acegi Security has no problems with you adding additional columns to the schema (or backend) managed by an AuthenticationDao. You can even return such additional details in the UserDetails implementation returned by the AuthenticationDao. I do not believe any of your use cases could not be effectively and modularly accommodated using the existing Acegi Security packages. Its usefulness for your authentication needs is beyond a doubt. The ACL side is a little grayer, simply because the ACL packages are quite new. Having said that, I am fairly confident they'd meet your needs as described in my earlier email. The ACL packages are reasonably flexible if you really wanted to completely re-engineer the schema: check the list archives for a recent discussion between Andres March and myself about this. In relation to remoting integration, as you may have noticed in the Contacts sample application, Acegi Security provides support for this via its BASIC authentication filter. In addition, there is a new RCP package which can be helpful for ensuring a valid login request has happened at the client end. Check out the Petclinic RCP sample (part of the spring-rcp project) to see this in use. I'd suggest trying to integrate authentication without worrying about the ACL side. Then, once you see that working, review how the included ACL packages work. It will be a lot clearer when you understand the place where the method security interceptors, ContextHolder, AuthenticationDao, and AccessDecisionVoters fit into the bigger picture. Of course we're also happy to continue helping you on-list. 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
RE: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
BTW, we use hibernate for all our data access. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Tuesday, August 17, 2004 5:35 PM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah ) Oliver Hutchison wrote: Using hibernate it is possible to do the following ( pseudo code ) SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.id = 1); Why not just use the username (which should be unique) to lookup the SalesPerson? SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.username = ?, user.getUsername()); Assuming there's and index on username performance would not be an issue. Ollie Hi Bryan I am inclined to agree with Ollie. Your other requirement (the last 20 users who signed up) could be equally as effectively addressed by an additional indexed column, createdDate. Acegi Security has no problems with you adding additional columns to the schema (or backend) managed by an AuthenticationDao. You can even return such additional details in the UserDetails implementation returned by the AuthenticationDao. I do not believe any of your use cases could not be effectively and modularly accommodated using the existing Acegi Security packages. Its usefulness for your authentication needs is beyond a doubt. The ACL side is a little grayer, simply because the ACL packages are quite new. Having said that, I am fairly confident they'd meet your needs as described in my earlier email. The ACL packages are reasonably flexible if you really wanted to completely re-engineer the schema: check the list archives for a recent discussion between Andres March and myself about this. In relation to remoting integration, as you may have noticed in the Contacts sample application, Acegi Security provides support for this via its BASIC authentication filter. In addition, there is a new RCP package which can be helpful for ensuring a valid login request has happened at the client end. Check out the Petclinic RCP sample (part of the spring-rcp project) to see this in use. I'd suggest trying to integrate authentication without worrying about the ACL side. Then, once you see that working, review how the included ACL packages work. It will be a lot clearer when you understand the place where the method security interceptors, ContextHolder, AuthenticationDao, and AccessDecisionVoters fit into the bigger picture. Of course we're also happy to continue helping you on-list. 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
RE: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
I agree. We have easily extended the ACL classes at logical points to handle our business particulars. The db schema was the first such issue. From what I have read on this thread, your use cases are pretty simple and you just need to learn more about how to extend acegi at the right places. The docs are pretty good for any software but the test cases are great. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Tuesday, August 17, 2004 5:35 PM To: [EMAIL PROTECTED] Subject: Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah ) Oliver Hutchison wrote: Using hibernate it is possible to do the following ( pseudo code ) SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.id = 1); Why not just use the username (which should be unique) to lookup the SalesPerson? SalesPerson salesPerson = hibernate.find( SalesPerson as salesperson where salesperson.username = ?, user.getUsername()); Assuming there's and index on username performance would not be an issue. Ollie Hi Bryan I am inclined to agree with Ollie. Your other requirement (the last 20 users who signed up) could be equally as effectively addressed by an additional indexed column, createdDate. Acegi Security has no problems with you adding additional columns to the schema (or backend) managed by an AuthenticationDao. You can even return such additional details in the UserDetails implementation returned by the AuthenticationDao. I do not believe any of your use cases could not be effectively and modularly accommodated using the existing Acegi Security packages. Its usefulness for your authentication needs is beyond a doubt. The ACL side is a little grayer, simply because the ACL packages are quite new. Having said that, I am fairly confident they'd meet your needs as described in my earlier email. The ACL packages are reasonably flexible if you really wanted to completely re-engineer the schema: check the list archives for a recent discussion between Andres March and myself about this. In relation to remoting integration, as you may have noticed in the Contacts sample application, Acegi Security provides support for this via its BASIC authentication filter. In addition, there is a new RCP package which can be helpful for ensuring a valid login request has happened at the client end. Check out the Petclinic RCP sample (part of the spring-rcp project) to see this in use. I'd suggest trying to integrate authentication without worrying about the ACL side. Then, once you see that working, review how the included ACL packages work. It will be a lot clearer when you understand the place where the method security interceptors, ContextHolder, AuthenticationDao, and AccessDecisionVoters fit into the bigger picture. Of course we're also happy to continue helping you on-list. 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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
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.
The way that I have been doing this previously ( with hibernate )
has been to do the following.
Create a SystemUser object ( id, name, password, username )
and add it to the session.
When I call my service bean the method call would be like this
public List getAllMyProperties(SystemUser user );
or
public List getAllMySalesStaff(SystemUser user );
or
public Integer addOrUpdateForSaleProperty(ForSaleProperty prop,
SystemUser user);
So I was thinking it would be cool if I could somehow get Acegi working
in such a
way that it would either set the user id onto the service bean or set it
onto the
systemUserHolder bean.
That way I would just be able to do this.
public Integer addOrUpdateForSaleProperty(ForSaleProperty prop) {
SystemUser user = this.systemUserHolder.getSystemUser;
return
this.propertyManipulationDAO.addOrUpdateForSaleProperty(ForSaleProperty
prop,SystemUser user)
}
This would make my service interfaces really clean and mean that it
would be a lot easier to expose them as web
services.
If it set the user/user id onto the systemUserHolder bean it would be
cool because
for unit testing I could swap it out with a mock class. If I were to call
SecureContext secureContext = ((SecureContext)
ContextHolder.getContext());
systemUser = ( SystemUser
)secureContext.getAuthentication().getDetails();
}
Directly from within the service bean it would make it
dependant on your framework and mean that I couldn't
unit test it without initialising security through
acegi.
I hope that this is a little clearer, to be honest
I'm better at understanding than explaining :-)
--b
Ben Alex wrote:
bryan wrote:
Then my methods that are in the orderService class can call
systemUserHolder.getSystemUser.getId() and do searches for example
where the user is only allowed
to see financial data for a certain region.
I am very much new to Spring so if I'm completely off the mark here
feel free to flame me. I think this code will be a good reference
implimentation if I can get it working good.
--b
Hi Bryan
Not sure what you're trying to do, but on first glance there should be
no need to have your orderServiceTarget have a reference to
systemUserHolder. Typically any security checks would take place
within an AccessDecisionVoter, which is handed the Authentication
object directly. Should the Authentication object require some custom
methods, you'd probably achieve that by implementing a custom
AuthenticationDao (assuming you're using DaoAuthenticationProvider,
which is most common). Now if the custom methods only relate to access
control, you'd be well served to check out the new
net.sf.acegisecurity.acl.basic package, as it would probably solve
your goals in a more efficient way.
If you could let the list know what you're trying to achieve at a
functional level, we'd be able to point you to specific classes and
interfaces to implement etc.
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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
Actually here is a good example of a future use of what I am planning on doing. This is not possible now but if I structure my application the way I am saying then it will be a great way to do it in the future. Filtering using hibernate 3 filters. http://www.theserverside.com/blogs/showblog.tss?id=Hibernate3Filters --- 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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
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? 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. 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). 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
Re: [Acegisecurity-developer] hibernate compatability ( blah blah blah )
bryan wrote: Then my methods that are in the orderService class can call systemUserHolder.getSystemUser.getId() and do searches for example where the user is only allowed to see financial data for a certain region. I am very much new to Spring so if I'm completely off the mark here feel free to flame me. I think this code will be a good reference implimentation if I can get it working good. --b Hi Bryan Not sure what you're trying to do, but on first glance there should be no need to have your orderServiceTarget have a reference to systemUserHolder. Typically any security checks would take place within an AccessDecisionVoter, which is handed the Authentication object directly. Should the Authentication object require some custom methods, you'd probably achieve that by implementing a custom AuthenticationDao (assuming you're using DaoAuthenticationProvider, which is most common). Now if the custom methods only relate to access control, you'd be well served to check out the new net.sf.acegisecurity.acl.basic package, as it would probably solve your goals in a more efficient way. If you could let the list know what you're trying to achieve at a functional level, we'd be able to point you to specific classes and interfaces to implement etc. 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
