Thanks Alex, just ignore my last email as you have explained in detail what I need to do in order to get going with Acegi.
The problem with #2 in my case is I don't know which SSO solution each implementtion will require. It can be SiteMinder, IBM's TAM or any other implementation. Also I need to provide a default AuthenticationProvider for cases where there is not SSO solution. The default implementation will be probably JDBC based. so #2 also makes #3 little chalanging. But I am sure with the help of this forum I can come up with a solution which will be flexable enough to meet our requirements. Amad --- Ben Alex <[EMAIL PROTECTED]> wrote: > Amad Fida wrote: > > >Thanks Ben, so would suggest rich client security > >packakge as starting point? > > > >Amad > > > > > > > I 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: > > 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 > __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com ------------------------------------------------------- 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
