Amad Fida wrote:
Thanks Ben, so would suggest rich client securityI tend to approach things based on the most risky part of the project first. That way you discover the constraints it will impose on the easier parts of the project, and can have more confidence in the schedule. With that in mind, it depends on what is most critical to your project and what you consider highest impact if it fails:
packakge as starting point?
Amad
1. Remoting integration with Brightside (seems low risk to me, but if Brightside is 100% critical, probably start there)
2. Coding additional AuthenticationProviders for your extra SSO implementations
3. Ensuring your AccessDecisionVoters have access to GrantedAuthority implementations with the necessary data to make a decision
4. Ensuring any access control list (domain object instance) security has been properly designed and integrated into the object model
5. Ensuring your Spring Rich actions can be disabled etc based on GrantedAuthoritys
#1 isn't particularly difficult, and #2 should theoretically be pretty easy given there are other providers to use as a basis, so I'd be more inclined to look at the greater unknown areas in #3, #4 and #5. #5 in particular could be a lot of work as it has dependencies on Spring Rich architecture. #3 and #4 are pretty standard things, but as you're writing your domain and services layers you need to ensure they're security-friendly in terms of method names, method arguments, how to wire in the security interceptor etc.
Best regards
Ben
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
