Re: [Acegisecurity-developer] Suggestion to optimize BasicAclEntryAfterInvocationCollectionFilteringProvider
Paulo Neves wrote: My suggestion is, if we optimize time to remove domain objects we optimize a lot all process. Hi Paulo To make it easier to discuss and reproduce scalability related issues with the ACL packages, I've modified the Contacts sample to automatically create 1,000 extra Contacts and associated ACL records at startup. The DataSourcePopulator also has a "createEntities" parameter which can be changed to a larger number. This is now checked into CVS. I had DataSourcePopulator create 10,000 entities, and then I did the following: maven multiwar:multiwar deploy acegi-security-sample-contacts-filter.war to Tomcat 5.5 visit the Contacts home page, then login as Marissa to view her contacts maven -Dusername=marissa -Dpassword=koala -DnrOfCalls=3 run maven -Dusername=dianne -Dpassword=emu -DnrOfCalls=3 run Then I repeated the above, but using your change to CollectionFilterer (of course I had to jar:install from /core firstly). Only HttpInvoker was used (this is now the default for Contacts). Initially it took 12,000 ms for Dianne and 12,047 for Marissa. With your changes it took 10,610 for Dianne and 10,687 for Marissa. A good improvement, but the similarity of the original execution times between Dianne and Marissa has me confused as to why your results reported a major difference in execution time between them. Would you please see if you can reproduce my results and perhaps re-check the original time difference between Dianne and Marissa. As an aside, I wouldn't generally be encouraging people to return 10,000 elements inside a Collection and then expect the ACL package to filter out all but 4 or 5 items. That sort of thing is an abuse of an RDBMS platform's inbuilt capabilities! :-) Still, we should aim to optimise the Java code as greatly as possible, so I am happy to explore this benchmarking and squeeze better performance out of it. Cheers Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] DaoAuthenticationProvider: Ordering of exceptions...
Wesley Hall wrote: So in conclusion, I am suggesting a change of order to... username valid? account locked? password correct? account enabled? account expired? password expired? Does this make sense? Am I missing anything else? I agree, that makes sense. I have made the change in CVS. Thanks Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Question about AbstractSecurityInterceptor
Mansoor, Ghazenfer (EDS) wrote: How about adding this check at one central place, AuthenticationManager? I am doing this and I do not see any problem. I set the authenticate to true after successful authentication, and check for isAuthentication() before every call. What sets your Authentication.isAuthenticated() back to false at the start of each request? I would propose the following: - SecurityContext to provide a startRequest() and finishRequest() method that is called by HttpSessionContextIntegrationFilter. - The startRequest() and finishRequest() set Authentication.isAuthenticated() to false. Do it twice in case the Authentication is being presented from a remote system (eg via RMI) which has set the isAuthenticated() to true. - An AuthenticationProvider may, but is not required to, set Authentication.isAuthenticated() to true. If it does set it to true, it means it does not require further callback and the Authentication can safely be used for the remainder of the request. AuthenticationProviders should provide a property setting so this can be switched off (ie they never set the flag to true) as in special situations (like chained AuthenticationProviders or a cache-aware ProviderManager) it might be undesirable. - AbstractSecurityInterceptor honours the Authentication.isAuthenticated() property by not calling AuthenticationManager if not required. AbstractSecurityInterceptor never sets Authentication.isAuthenticated() (it does at present) This means there are only two actors changing the Authentication.isAuthenticated() flag: HttpSessionContextIntegrationFilter to clear it, and an AuthenticationProvider to set it. You are only considering DAO authentication provider here, how about the other providers that do not have caching? Most AuthenticationProvider implementations use caching. At least the CAS, X.509 and DAO providers do, and they're the main ones people use. Besides, I was supporting that we should address this issue, just noting it isn't a critical performance issue at present. The benefit of these changes is mainly going to be avoiding unnecessary interaction with collections in ProviderManager and the various caches, plus providing a request-specific hook for future expansion. That should improve performance, although today's collection implementations are fairly well-optimised. Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] runas without authentication
Ben Alex wrote: I think your use case would be better suited to the anonymous authentication capability. It is especially designed for giving an unauthenticated request an Authentication, and the SecurityEnforcementFilter recognises the fact it is an anonymous Authentication and will redirect to the AuthenticationEntryPoint in the event of an AccessDeniedException (as opposed to returning a 403 / SC_FORBIDDEN). that sounds right. i don't have any need for access control on this operation, so it looks like i can simply use anonymous authen and then have my jackrabbit access manager use an AuthenticationTrustResolver to see if the Authentication is anonymous. i think that will work. thanks! --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Question about AbstractSecurityInterceptor
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Tuesday, May 17, 2005 6:00 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Question about AbstractSecurityInterceptor Venkat Sonnathi wrote: >Hi, > >I am exploring AcegiSecurity by following the contacts sample >application. I observed that in >AbstractSecurityInterceptor.beforeInvocation method >authenticationManager.authenticate is being called for every request. >Why is it? Can it be optimized to check if authentication is already >done and skip this step? > >For every click the above method is called twice: once as part of >FilterSecurityInterceptor and once as part of MethodSecurityInterceptor >and if we optimize/check for authentication then the call to >authenticationManager.authenticate can be avoided. > >Thanks, >--Venkat. > > > >Yes, it could be optimised using a range of strategies such as putting a flag into the ContextHolder > (SecurityContextHolder in CVS and from 0.9.0). The trouble is then causing that flag to reset at the start of each > request so that only the first AbstractSecurityInterceptor invocation causes delegation to the AuthenticationManager. > Indeed if the request was actually authenticated during the request by an authentication mechanism (eg BASIC/Digest/form > post) we should accept that AuthenticationManager invocation and not require any AbstractSecurityInterceptor to repeat > it. How about adding this check at one central place, AuthenticationManager? I am doing this and I do not see any problem. I set the authenticate to true after successful authentication, and check for isAuthentication() before every call. > We could refresh the SecurityContextHolder flag this in the HttpSessionContextIntegrationFilter, but then we're reducing > its focus on simply storing the SecurityContext between HTTP requests. Better yet, we could have startRequest() and > finishRequest() methods in the SecurityContext to encapsulate this sort of logic and have the > HttpSessionContextIntegrationFilter call them. Indeed that might prove beneficial for Captcha integration, which also > needs to set a once-per-request style flag. What do others think? > I have not performed any benchmarks, but given that caching is performed in AuthenticationProvider implementations I > would not suspect the double-up of AuthenticationManager invocations would represent an urgent performance constraint at > this time. You are only considering DAO authentication provider here, how about the other providers that do not have caching? Regards Ghazenfer --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Question about AbstractSecurityInterceptor
Venkat Sonnathi wrote: Hi, I am exploring AcegiSecurity by following the contacts sample application. I observed that in AbstractSecurityInterceptor.beforeInvocation method authenticationManager.authenticate is being called for every request. Why is it? Can it be optimized to check if authentication is already done and skip this step? For every click the above method is called twice: once as part of FilterSecurityInterceptor and once as part of MethodSecurityInterceptor and if we optimize/check for authentication then the call to authenticationManager.authenticate can be avoided. Thanks, --Venkat. Yes, it could be optimised using a range of strategies such as putting a flag into the ContextHolder (SecurityContextHolder in CVS and from 0.9.0). The trouble is then causing that flag to reset at the start of each request so that only the first AbstractSecurityInterceptor invocation causes delegation to the AuthenticationManager. Indeed if the request was actually authenticated during the request by an authentication mechanism (eg BASIC/Digest/form post) we should accept that AuthenticationManager invocation and not require any AbstractSecurityInterceptor to repeat it. We could refresh the SecurityContextHolder flag this in the HttpSessionContextIntegrationFilter, but then we're reducing its focus on simply storing the SecurityContext between HTTP requests. Better yet, we could have startRequest() and finishRequest() methods in the SecurityContext to encapsulate this sort of logic and have the HttpSessionContextIntegrationFilter call them. Indeed that might prove beneficial for Captcha integration, which also needs to set a once-per-request style flag. What do others think? I have not performed any benchmarks, but given that caching is performed in AuthenticationProvider implementations I would not suspect the double-up of AuthenticationManager invocations would represent an urgent performance constraint at this time. Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] runas without authentication
Brian Moseley wrote: it seems like the runas facilities might be able to give me what i want. is there a way to set up acegi security so that the http request itself is not authenticated but runas is used specifically only for the repository login? Hi Brian Run-as replacement is more often used to change the active principal - or their GrantedAuthority[]s - so that methods can invoke remote methods that might require a different security realm. So if your SignUpManager needed to create a DNS domain, and the DnsManager was on a shared system for which the ASP was given an ASP-wide login, run-as replacement would be used so that during execution of SignUpManager the active principal could change to that of the ASP (ready for the remote invocation). I think your use case would be better suited to the anonymous authentication capability. It is especially designed for giving an unauthenticated request an Authentication, and the SecurityEnforcementFilter recognises the fact it is an anonymous Authentication and will redirect to the AuthenticationEntryPoint in the event of an AccessDeniedException (as opposed to returning a 403 / SC_FORBIDDEN). Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Suggestion to optimize BasicAclEntryAfterInvocationCollectionFilteringProvider
Hi all,
I'm testing ACL on acegi with the following scene:
Application Contacts with 10010 contacts.
Where
dianne have access to 4 conctacts
scott have access to 5 contacts
marissa have access to all contacts
When I run getAll() , this (with cache) I obtain following execution times:
dianne : 800 ms
scott: 825 ms
marissa: 250 ~ 285 ms
Because of this diference (marissa between others) I debug
BasicAclEntryAfterInvocationCollectionFilteringProvider method and I
discover that getFilteredObject() occupies 300~350 ms.
So I change CollectionFilterer class to remove object directly from
iterator, like this:
/**
* A filter used to filter Collections.
*/
class CollectionFilterer implements Filterer {
...
private Collection collection;
private Set removeList;
private Iterator collectionIter;
/**
* @see net.sf.acegisecurity.afterinvocation.Filterer#iterator()
*/
public Iterator iterator() {
collectionIter = collection.iterator();
return collectionIter;
}
/**
* @see
net.sf.acegisecurity.afterinvocation.Filterer#remove(java.lang.Object)
*/
public void remove(Object object) {
//removeList.add(object);
//this.collection.remove(object);
collectionIter.remove();
}
}
( I change this only to test purpose )
When I run it again I obtain following execution times:
dianne : 203~344 ms
scott: (don't run with scott)
marissa: with same times
My suggestion is, if we optimize time to remove domain objects we
optimize a lot all process.
Ps: Sorry my english.
Thanks,
Paulo
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Question about AbstractSecurityInterceptor
Hi, I am exploring AcegiSecurity by following the contacts sample application. I observed that in AbstractSecurityInterceptor.beforeInvocation method authenticationManager.authenticate is being called for every request. Why is it? Can it be optimized to check if authentication is already done and skip this step? For every click the above method is called twice: once as part of FilterSecurityInterceptor and once as part of MethodSecurityInterceptor and if we optimize/check for authentication then the call to authenticationManager.authenticate can be avoided. Thanks, --Venkat. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
